llvm dev - Dec 2012 - [LLVMdev] Trying out Loop Vectorizer

On Dec 31, 2012, at 11:57 AM, Benjamin Kramer <benny.kra at gmail.com>
wrote:
> I'm not entirely sure why this is the case, the target specific stuff
for opt is still very new, but at the moment you have to explicitly set a triple
for opt so it can access target-specific bits to estimate the cost of
vectorization.
I think that this is a good opportunity to discuss this topic.  At the moment
'opt' does not use the triple that is found in the module in order to
initialize the backend and the backend related analysis passes. It relies on the
'-mtriple' command line flag. LLC on the other hand uses the host
triple. I see the following options:

1. 'opt' does not initialize the backend passes unless
'-mtriple' is used. (the current option)
2. 'opt' grabs the triple from the bit code file and uses it to
initialize the backend passes.
3. 'opt' gets the default target triple (like llc).

I think that Nick said that he prefers #2.

Nadav 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20121231/b1e92ded/attachment.html>

On Mon, Dec 31, 2012 at 3:26 PM, Nadav Rotem <nrotem at apple.com> wrote:
>
> On Dec 31, 2012, at 11:57 AM, Benjamin Kramer <benny.kra at
gmail.com> wrote:
>
> I'm not entirely sure why this is the case, the target specific stuff
for
> opt is still very new, but at the moment you have to explicitly set a
> triple for opt so it can access target-specific bits to estimate the cost
> of vectorization.
>
>
> I think that this is a good opportunity to discuss this topic.  At the
> moment 'opt' does not use the triple that is found in the module in
order
> to initialize the backend and the backend related analysis passes. It
> relies on the '-mtriple' command line flag. LLC on the other hand
uses the
> host triple. I see the following options:
>
> 1. 'opt' does not initialize the backend passes unless
'-mtriple' is used.
> (the current option)
> 2. 'opt' grabs the triple from the bit code file and uses it to
initialize
> the backend passes.
> 3. 'opt' gets the default target triple (like llc).
>
My only strong opinion is that I dislike #3.

I have a mild preference for encoding more in bitcode and less in
commandline switches, while still allowing commandline switches to override
what is in the bitcode.

>
> I think that Nick said that he prefers #2.
>
> Nadav
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20121231/1191d6c5/attachment.html>

----- Original Message -----
> From: "Nadav Rotem" <nrotem at apple.com>
> To: "Benjamin Kramer" <benny.kra at gmail.com>
> Cc: "llvmdev at cs.uiuc.edu List" <llvmdev at cs.uiuc.edu>
> Sent: Monday, December 31, 2012 5:26:18 PM
> Subject: Re: [LLVMdev] Trying out Loop Vectorizer
> 
> 
> 
> 
> 
> On Dec 31, 2012, at 11:57 AM, Benjamin Kramer < benny.kra at gmail.com
>
> wrote:
> 
> 
> I'm not entirely sure why this is the case, the target specific stuff
> for opt is still very new, but at the moment you have to explicitly
> set a triple for opt so it can access target-specific bits to
> estimate the cost of vectorization.
> 
> I think that this is a good opportunity to discuss this topic. At the
> moment 'opt' does not use the triple that is found in the module in
> order to initialize the backend and the backend related analysis
> passes. It relies on the '-mtriple' command line flag. LLC on the
> other hand uses the host triple. I see the following options:
> 
> 
> 1. 'opt' does not initialize the backend passes unless
'-mtriple' is
> used. (the current option)
> 2. 'opt' grabs the triple from the bit code file and uses it to
> initialize the backend passes.
> 3. 'opt' gets the default target triple (like llc).
> 
> 
> I think that Nick said that he prefers #2.
As do I.

 -Hal
> 
> 
> Nadav
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory

On Jan 1, 2013, at 12:31 AM, Chandler Carruth <chandlerc at google.com>
wrote:
> On Mon, Dec 31, 2012 at 3:26 PM, Nadav Rotem <nrotem at apple.com>
wrote:
>> 
>> On Dec 31, 2012, at 11:57 AM, Benjamin Kramer <benny.kra at
gmail.com> wrote:
>> 
>>> I'm not entirely sure why this is the case, the target specific
stuff for opt is still very new, but at the moment you have to explicitly set a
triple for opt so it can access target-specific bits to estimate the cost of
vectorization.
>> 
>> I think that this is a good opportunity to discuss this topic.  At the
moment 'opt' does not use the triple that is found in the module in
order to initialize the backend and the backend related analysis passes. It
relies on the '-mtriple' command line flag. LLC on the other hand uses
the host triple. I see the following options:
>> 
>> 1. 'opt' does not initialize the backend passes unless
'-mtriple' is used. (the current option)
>> 2. 'opt' grabs the triple from the bit code file and uses it to
initialize the backend passes.
>> 3. 'opt' gets the default target triple (like llc).
> 
> My only strong opinion is that I dislike #3.
> 
> I have a mild preference for encoding more in bitcode and less in
commandline switches, while still allowing commandline switches to override what
is in the bitcode.
+1 on both points.  Both opt and llc should work this way.  To get llc's
current behavior, you should have to pass -mcpu=native or something, explicitly.

-Chris

>> 
>> I think that Nick said that he prefers #2.
>> 
>> Nadav 
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130101/af1c9f13/attachment.html>