Flag to print vectorized loops

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Flag to print vectorized loops

Sebastian Pop-7
Hi,

Nadav Rotem wrote:
>
> On Nov 26, 2012, at 1:46 PM, Sebastian Pop <[hidden email]> wrote:
> > It would be a quick and easy contribution to add a flag to print on stdout the
> > loops being vectorized.
>
> Okay. I am not sure how chris feels about printing to stdout. We should bring it up on the mailing list.

Both GCC and ICC have a flag that prints out a message when a loop has been
vectorized.  Would the attached patch be ok to commit?

Thanks,
Sebastian
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

0001-add-flag-print-vectorized-loops.patch (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Flag to print vectorized loops

Nadav Rotem
Hi Sebastian,

Thanks for looking at this.  I don't think that printing to stdout is the right thing to do. I think that we need to go through the clang driver.  

Nadav

On Nov 26, 2012, at 3:20 PM, Sebastian Pop <[hidden email]> wrote:

> Hi,
>
> Nadav Rotem wrote:
>>
>> On Nov 26, 2012, at 1:46 PM, Sebastian Pop <[hidden email]> wrote:
>>> It would be a quick and easy contribution to add a flag to print on stdout the
>>> loops being vectorized.
>>
>> Okay. I am not sure how chris feels about printing to stdout. We should bring it up on the mailing list.
>
> Both GCC and ICC have a flag that prints out a message when a loop has been
> vectorized.  Would the attached patch be ok to commit?
>
> Thanks,
> Sebastian
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
> <0001-add-flag-print-vectorized-loops.patch>

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Flag to print vectorized loops

Sebastian Pop-7
Nadav Rotem wrote:
> I don't think that printing to stdout is the right thing to do. I think that
> we need to go through the clang driver.

I'm not sure I understand exactly what you are suggesting: could you please give
some more details?  Do you mean that we should use clang's diagnostic
infrastructure to report these messages?

Thanks,
Sebastian
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-commits] Flag to print vectorized loops

Hal Finkel
In reply to this post by Sebastian Pop-7
----- Original Message -----

> From: "Sebastian Pop" <[hidden email]>
> To: "Nadav Rotem" <[hidden email]>, [hidden email], [hidden email]
> Sent: Monday, November 26, 2012 5:20:47 PM
> Subject: [llvm-commits] Flag to print vectorized loops
>
> Hi,
>
> Nadav Rotem wrote:
> >
> > On Nov 26, 2012, at 1:46 PM, Sebastian Pop <[hidden email]>
> > wrote:
> > > It would be a quick and easy contribution to add a flag to print
> > > on stdout the
> > > loops being vectorized.
> >
> > Okay. I am not sure how chris feels about printing to stdout. We
> > should bring it up on the mailing list.
>
> Both GCC and ICC have a flag that prints out a message when a loop
> has been
> vectorized.  Would the attached patch be ok to commit?

Sebastian,

In my opinion, what we really need is an interface that the frontend can use to get information from the backend optimizers. Then the frontend can display this information to users in an appropriate way. Furthermore, this information should be structured (we already have a YAML parser, so that might be a good choice), and should probably directly take a Value *, BasicBlock *, Function *, etc. so that the frontend can do the appropriate mapping for the user.

 -Hal

>
> Thanks,
> Sebastian
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> hosted by The Linux Foundation
>
> _______________________________________________
> llvm-commits mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>

--
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-commits] Flag to print vectorized loops

Sean Silva
> In my opinion, what we really need is an interface that the frontend can use to get information from the backend optimizers. Then the frontend can display this information to users in an appropriate way. Furthermore, this information should be structured (we already have a YAML parser, so that might be a good choice), and should probably directly take a Value *, BasicBlock *, Function *, etc. so that the frontend can do the appropriate mapping for the user.

Another possibility is to use clang's diagnostics infrastructure. That
is, generalize the diagnostic infrastructure to the rest of LLVM. I'm
not sure what the tradeoff would be for that compared with your
suggestion. Actually, they might be orthogonal issues. In Matt
Beaumont-Gay's dev meeting talk about clang diagnostics, it appeared
that one of the issues he had to battle with was the lack of a
structured representation for diagnostics, which suggests that a
structured representation is indeed orthogonal.

So basically, this kind of optimization notice could be emitted as a
"note" through a DiagnosticsEngine stored in the LLVMContext. When
clang is calling into LLVM, it would pass down its DiagnosticsEngine
and so these diagnostics would be seamlessly integrated.

LLD is also eventually going to eventually grow into the need for a
proper diagnostics framework as well, which further strengthens the
idea to generalize the diagnostics infrastructure to be a general part
of LLVM.

-- Sean Silva

On Mon, Nov 26, 2012 at 6:46 PM, Hal Finkel <[hidden email]> wrote:

> ----- Original Message -----
>> From: "Sebastian Pop" <[hidden email]>
>> To: "Nadav Rotem" <[hidden email]>, [hidden email], [hidden email]
>> Sent: Monday, November 26, 2012 5:20:47 PM
>> Subject: [llvm-commits] Flag to print vectorized loops
>>
>> Hi,
>>
>> Nadav Rotem wrote:
>> >
>> > On Nov 26, 2012, at 1:46 PM, Sebastian Pop <[hidden email]>
>> > wrote:
>> > > It would be a quick and easy contribution to add a flag to print
>> > > on stdout the
>> > > loops being vectorized.
>> >
>> > Okay. I am not sure how chris feels about printing to stdout. We
>> > should bring it up on the mailing list.
>>
>> Both GCC and ICC have a flag that prints out a message when a loop
>> has been
>> vectorized.  Would the attached patch be ok to commit?
>
> Sebastian,
>
> In my opinion, what we really need is an interface that the frontend can use to get information from the backend optimizers. Then the frontend can display this information to users in an appropriate way. Furthermore, this information should be structured (we already have a YAML parser, so that might be a good choice), and should probably directly take a Value *, BasicBlock *, Function *, etc. so that the frontend can do the appropriate mapping for the user.
>
>  -Hal
>
>>
>> Thanks,
>> Sebastian
>> --
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>> hosted by The Linux Foundation
>>
>> _______________________________________________
>> llvm-commits mailing list
>> [hidden email]
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
>
> --
> Hal Finkel
> Postdoctoral Appointee
> Leadership Computing Facility
> Argonne National Laboratory
> _______________________________________________
> llvm-commits mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Flag to print vectorized loops

Nadav Rotem
In reply to this post by Sebastian Pop-7
I don't think that IR-level passes should just print messages into stdout.  I think that all of the input/output should be handled by the compiler driver. There needs to be an interface that will allow us to build something useful on top of it, such as color messages or IDE integration.

On Nov 26, 2012, at 3:28 PM, Sebastian Pop <[hidden email]> wrote:

> Nadav Rotem wrote:
>> I don't think that printing to stdout is the right thing to do. I think that
>> we need to go through the clang driver.
>
> I'm not sure I understand exactly what you are suggesting: could you please give
> some more details?  Do you mean that we should use clang's diagnostic
> infrastructure to report these messages?
>
> Thanks,
> Sebastian
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-commits] Flag to print vectorized loops

Nadav Rotem
In reply to this post by Hal Finkel

On Nov 26, 2012, at 3:46 PM, Hal Finkel <[hidden email]> wrote:


In my opinion, what we really need is an interface that the frontend can use to get information from the backend optimizers. Then the frontend can display this information to users in an appropriate way.

I  agree. 

Furthermore, this information should be structured (we already have a YAML parser, so that might be a good choice),

YAML is a great way to serialize these messages, and pass them to IDEs, etc.  But I think that we should start discussing the interfaces. 

and should probably directly take a Value *, BasicBlock *, Function *, etc. so that the frontend can do the appropriate mapping for the user.


+1 


Thanks,
Nadav

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-commits] Flag to print vectorized loops

Chris Lattner-2

On Nov 26, 2012, at 6:00 PM, Nadav Rotem <[hidden email]> wrote:


On Nov 26, 2012, at 3:46 PM, Hal Finkel <[hidden email]> wrote:


In my opinion, what we really need is an interface that the frontend can use to get information from the backend optimizers. Then the frontend can display this information to users in an appropriate way.

I  agree. 

Furthermore, this information should be structured (we already have a YAML parser, so that might be a good choice),

YAML is a great way to serialize these messages, and pass them to IDEs, etc.  But I think that we should start discussing the interfaces. 

and should probably directly take a Value *, BasicBlock *, Function *, etc. so that the frontend can do the appropriate mapping for the user.


+1 

IMO, the right way to build this is something like "InlineAsmDiagnosticHandler" in LLVMContext (but hopefully better, and more structured :).  The basic jist of it is that the backend can push messages up, and the frontend can register its hooks to render them however it likes.  In this case, I agree that clang "Notes" or some new "informational" diagnostic is probably the right way to go.  

-Chris


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-commits] Flag to print vectorized loops

Sean Silva
> IMO, the right way to build this is something like
> "InlineAsmDiagnosticHandler" in LLVMContext (but hopefully better, and more
> structured :)

Hey Chris,

Did you catch my suggestion in reply to Hal, about maybe generalizing
Clang's diagnostics infrastructure up into LLVM? Your reply seems
along the same lines. It seems like a natural fit to reuse that rather
than make another one (and it would permit seamless integration).
Also, presumably LLD is going to be giving sweet diagnostics some day,
and this change would be analogous to the work that Michael Spencer
has been doing lifting and generalizing the option-parsing stuff from
Clang. What do you think about that approach?

-- Sean

On Mon, Nov 26, 2012 at 9:03 PM, Chris Lattner <[hidden email]> wrote:

>
> On Nov 26, 2012, at 6:00 PM, Nadav Rotem <[hidden email]> wrote:
>
>
> On Nov 26, 2012, at 3:46 PM, Hal Finkel <[hidden email]> wrote:
>
>
>
> In my opinion, what we really need is an interface that the frontend can use
> to get information from the backend optimizers. Then the frontend can
> display this information to users in an appropriate way.
>
>
> I  agree.
>
> Furthermore, this information should be structured (we already have a YAML
> parser, so that might be a good choice),
>
>
> YAML is a great way to serialize these messages, and pass them to IDEs, etc.
> But I think that we should start discussing the interfaces.
>
> and should probably directly take a Value *, BasicBlock *, Function *, etc.
> so that the frontend can do the appropriate mapping for the user.
>
>
> +1
>
>
> IMO, the right way to build this is something like
> "InlineAsmDiagnosticHandler" in LLVMContext (but hopefully better, and more
> structured :).  The basic jist of it is that the backend can push messages
> up, and the frontend can register its hooks to render them however it likes.
> In this case, I agree that clang "Notes" or some new "informational"
> diagnostic is probably the right way to go.
>
> -Chris
>
>
> _______________________________________________
> llvm-commits mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-commits] Flag to print vectorized loops

Eli Friedman-2
On Mon, Nov 26, 2012 at 6:26 PM, Sean Silva <[hidden email]> wrote:

>> IMO, the right way to build this is something like
>> "InlineAsmDiagnosticHandler" in LLVMContext (but hopefully better, and more
>> structured :)
>
> Hey Chris,
>
> Did you catch my suggestion in reply to Hal, about maybe generalizing
> Clang's diagnostics infrastructure up into LLVM? Your reply seems
> along the same lines. It seems like a natural fit to reuse that rather
> than make another one (and it would permit seamless integration).
> Also, presumably LLD is going to be giving sweet diagnostics some day,
> and this change would be analogous to the work that Michael Spencer
> has been doing lifting and generalizing the option-parsing stuff from
> Clang. What do you think about that approach?

clang's diagnostic code is inseparably tied to clang's SourceManager,
which really only makes sense for code using clang's Lex library.  It
might make sense to have a simpler diagnostic printing library in LLVM
even if clang can't use it.

-Eli
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-commits] Flag to print vectorized loops

Sean Silva
On Mon, Nov 26, 2012 at 9:33 PM, Eli Friedman <[hidden email]> wrote:
>
> clang's diagnostic code is inseparably tied to clang's SourceManager,
> which really only makes sense for code using clang's Lex library.

Bummer.

-- Sean Silva
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-commits] Flag to print vectorized loops

Hal Finkel
In reply to this post by Eli Friedman-2
----- Original Message -----

> From: "Eli Friedman" <[hidden email]>
> To: "Sean Silva" <[hidden email]>
> Cc: [hidden email], "Sebastian Pop" <[hidden email]>, [hidden email]
> Sent: Monday, November 26, 2012 8:33:51 PM
> Subject: Re: [llvm-commits] [LLVMdev]  Flag to print vectorized loops
>
> On Mon, Nov 26, 2012 at 6:26 PM, Sean Silva <[hidden email]>
> wrote:
> >> IMO, the right way to build this is something like
> >> "InlineAsmDiagnosticHandler" in LLVMContext (but hopefully better,
> >> and more
> >> structured :)
> >
> > Hey Chris,
> >
> > Did you catch my suggestion in reply to Hal, about maybe
> > generalizing
> > Clang's diagnostics infrastructure up into LLVM? Your reply seems
> > along the same lines. It seems like a natural fit to reuse that
> > rather
> > than make another one (and it would permit seamless integration).
> > Also, presumably LLD is going to be giving sweet diagnostics some
> > day,
> > and this change would be analogous to the work that Michael Spencer
> > has been doing lifting and generalizing the option-parsing stuff
> > from
> > Clang. What do you think about that approach?
>
> clang's diagnostic code is inseparably tied to clang's SourceManager,
> which really only makes sense for code using clang's Lex library.  It
> might make sense to have a simpler diagnostic printing library in
> LLVM
> even if clang can't use it.

Printing notices is one useful way this information can be used, but not the only method. This information can also be used in IDEs for hover-over popups (and similar UI widgets). One generic capability that clang should eventually provide is the generation of 'listing' files. These are copies of the source code where each line is annotated with information on what optimizations were performed and/or hints on why some common or requested optimization was not performed.

 -Hal

>
> -Eli
> _______________________________________________
> llvm-commits mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>

--
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev