disabling combining load/stores in optimizer.

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

disabling combining load/stores in optimizer.

sanjiv gupta-2

Consider writes to a struct {i32 a; i32 b};

 

The optimizer can currently combine stores (i32, i32) to a single i64 store operation. Is there a way to disable that?

 

I feel that such optimizations may not result in any gain for PIC16 as PIC16 does everything on i8.

 

 

 

- Sanjiv

 

 


_______________________________________________
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: disabling combining load/stores in optimizer.

Dan Gohman-2

On Aug 2, 2009, at 11:08 PM, [hidden email] wrote:


> Consider writes to a struct {i32 a; i32 b};
>
> The optimizer can currently combine stores (i32, i32) to a single  
> i64 store operation. Is there a way to disable that?

Not currently. There are some ideas floating around about
including in TargetData a list of integer types that the
target natively supports, which would allow instcombine
and other passes to make more informed decisions, but
at this point it's just ideas.

> I feel that such optimizations may not result in any gain for PIC16  
> as PIC16 does everything on i8.

The legalize pass should turn an i64 store into 8 i8 stores
then, which is essentially the same as what an {i32,i32} store
would turn into. Is there a problem with this?

Dan

_______________________________________________
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: disabling combining load/stores in optimizer.

Alireza.Moshtaghi
> > The optimizer can currently combine stores (i32, i32) to a single
> > i64 store operation. Is there a way to disable that?
>
> Not currently. There are some ideas floating around about
> including in TargetData a list of integer types that the
> target natively supports, which would allow instcombine
> and other passes to make more informed decisions, but
> at this point it's just ideas.

There are other cases that we can benefit from such ideas. Could you
please give pointer to these discussions?

>
> > I feel that such optimizations may not result in any gain for PIC16
> > as PIC16 does everything on i8.
>
> The legalize pass should turn an i64 store into 8 i8 stores
> then, which is essentially the same as what an {i32,i32} store
> would turn into. Is there a problem with this?
>

We are currently doing this, however I think disabling such
optimizations is a much better solution.

_______________________________________________
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: disabling combining load/stores in optimizer.

Chris Lattner-2

On Aug 3, 2009, at 1:20 PM, [hidden email] wrote:

>>> The optimizer can currently combine stores (i32, i32) to a single
>>> i64 store operation. Is there a way to disable that?
>>
>> Not currently. There are some ideas floating around about
>> including in TargetData a list of integer types that the
>> target natively supports, which would allow instcombine
>> and other passes to make more informed decisions, but
>> at this point it's just ideas.
>
> There are other cases that we can benefit from such ideas. Could you
> please give pointer to these discussions?

See "Adding legal integer sizes to TargetData" on Feb 1, 2009 on  
llvmdev.

-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: disabling combining load/stores in optimizer.

Dan Gohman-2
In reply to this post by Alireza.Moshtaghi

On Aug 3, 2009, at 1:20 PM, [hidden email] wrote:

>>
>>> I feel that such optimizations may not result in any gain for PIC16
>>>
>>> as PIC16 does everything on i8.
>>>
>>
>>
>> The legalize pass should turn an i64 store into 8 i8 stores
>>
>> then, which is essentially the same as what an {i32,i32} store
>>
>> would turn into. Is there a problem with this?
>>
>>
>>
>
> We are currently doing this, however I think disabling such
> optimizations is a much better solution.

An LLVM design goal is that backends should be able to outsmart
instcombine when necessary, rather than having instcombine be able
to disable parts of itself in order to avoid foiling the backends.
Practicality sometimes steers elsewhere of course. Please explain
why you think suppressing this particular optimization is better;
it isn't obvious how it would look different in the end.

Dan

_______________________________________________
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: disabling combining load/stores in optimizer.

Eli Friedman-2
On Mon, Aug 3, 2009 at 3:09 PM, Dan Gohman<[hidden email]> wrote:

>
> On Aug 3, 2009, at 1:20 PM, [hidden email] wrote:
>>>
>>>> I feel that such optimizations may not result in any gain for PIC16
>>>>
>>>> as PIC16 does everything on i8.
>>>>
>>>
>>>
>>> The legalize pass should turn an i64 store into 8 i8 stores
>>>
>>> then, which is essentially the same as what an {i32,i32} store
>>>
>>> would turn into. Is there a problem with this?
>>>
>>>
>>>
>>
>> We are currently doing this, however I think disabling such
>> optimizations is a much better solution.
>
> An LLVM design goal is that backends should be able to outsmart
> instcombine when necessary, rather than having instcombine be able
> to disable parts of itself in order to avoid foiling the backends.
> Practicality sometimes steers elsewhere of course. Please explain
> why you think suppressing this particular optimization is better;
> it isn't obvious how it would look different in the end.

Perhaps the transformation in question is actually memcpy->scalar
load+store?  For a target where the scalar takes more than a couple
registers, if the backend can't disambiguate the pointers, it's
essentially forced to copy src->stack temporary->dest.  For an 64-bit
memcpy on a target with 8-bit registers, I imagine the result is quite
ugly.

-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: disabling combining load/stores in optimizer.

Chris Lattner-2
In reply to this post by Dan Gohman-2

On Aug 3, 2009, at 3:09 PM, Dan Gohman wrote:

>>
>> We are currently doing this, however I think disabling such
>> optimizations is a much better solution.
>
> An LLVM design goal is that backends should be able to outsmart
> instcombine when necessary, rather than having instcombine be able
> to disable parts of itself in order to avoid foiling the backends.
> Practicality sometimes steers elsewhere of course. Please explain
> why you think suppressing this particular optimization is better;
> it isn't obvious how it would look different in the end.

Yeah, I agree.  LegalizeTypes should be able to trivially lower this.

-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: disabling combining load/stores in optimizer.

dag-7
On Monday 03 August 2009 18:01, Chris Lattner wrote:

> On Aug 3, 2009, at 3:09 PM, Dan Gohman wrote:
> >> We are currently doing this, however I think disabling such
> >> optimizations is a much better solution.
> >
> > An LLVM design goal is that backends should be able to outsmart
> > instcombine when necessary, rather than having instcombine be able
> > to disable parts of itself in order to avoid foiling the backends.
> > Practicality sometimes steers elsewhere of course. Please explain
> > why you think suppressing this particular optimization is better;
> > it isn't obvious how it would look different in the end.
>
> Yeah, I agree.  LegalizeTypes should be able to trivially lower this.

"Should be" is the key clause here.  I agree with you and Dan in general.
However, we have at least one testcase where the overhead of legalize is
so huge it takes *hours* to finish.  This is with LLVM 2.4 and I'm waiting
on an LLVM 2.5 upgrade to re-test so I can file a bug if necessary.

The point is that while legalize should be able to handle stuff, sometimes
it can't for other reasons.

                                  -Dave
_______________________________________________
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: disabling combining load/stores in optimizer.

Eli Friedman-2
On Mon, Aug 3, 2009 at 4:34 PM, David Greene<[hidden email]> wrote:

> On Monday 03 August 2009 18:01, Chris Lattner wrote:
>> On Aug 3, 2009, at 3:09 PM, Dan Gohman wrote:
>> >> We are currently doing this, however I think disabling such
>> >> optimizations is a much better solution.
>> >
>> > An LLVM design goal is that backends should be able to outsmart
>> > instcombine when necessary, rather than having instcombine be able
>> > to disable parts of itself in order to avoid foiling the backends.
>> > Practicality sometimes steers elsewhere of course. Please explain
>> > why you think suppressing this particular optimization is better;
>> > it isn't obvious how it would look different in the end.
>>
>> Yeah, I agree.  LegalizeTypes should be able to trivially lower this.
>
> "Should be" is the key clause here.  I agree with you and Dan in general.
> However, we have at least one testcase where the overhead of legalize is
> so huge it takes *hours* to finish.  This is with LLVM 2.4 and I'm waiting
> on an LLVM 2.5 upgrade to re-test so I can file a bug if necessary.

That doesn't seem relevant; we shouldn't mess with transformation
passes to hide performance issues in CodeGen.

-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: disabling combining load/stores in optimizer.

Chris Lattner-2

On Aug 3, 2009, at 5:16 PM, Eli Friedman wrote:

> On Mon, Aug 3, 2009 at 4:34 PM, David Greene<[hidden email]> wrote:
>> On Monday 03 August 2009 18:01, Chris Lattner wrote:
>>> On Aug 3, 2009, at 3:09 PM, Dan Gohman wrote:
>>>>> We are currently doing this, however I think disabling such
>>>>> optimizations is a much better solution.
>>>>
>>>> An LLVM design goal is that backends should be able to outsmart
>>>> instcombine when necessary, rather than having instcombine be able
>>>> to disable parts of itself in order to avoid foiling the backends.
>>>> Practicality sometimes steers elsewhere of course. Please explain
>>>> why you think suppressing this particular optimization is better;
>>>> it isn't obvious how it would look different in the end.
>>>
>>> Yeah, I agree.  LegalizeTypes should be able to trivially lower  
>>> this.
>>
>> "Should be" is the key clause here.  I agree with you and Dan in  
>> general.
>> However, we have at least one testcase where the overhead of  
>> legalize is
>> so huge it takes *hours* to finish.  This is with LLVM 2.4 and I'm  
>> waiting
>> on an LLVM 2.5 upgrade to re-test so I can file a bug if necessary.
>
> That doesn't seem relevant; we shouldn't mess with transformation
> passes to hide performance issues in CodeGen.

What Eli said. :)

It sounds like a bug in legalize if so, a bug we should fix!  That  
said, if there are well understood reasons why the code generator is  
not doing something, and if it isn't likely to change in the near  
future, we can consider making the optimizer aware of legal integer  
types.

-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: disabling combining load/stores in optimizer.

Alireza.Moshtaghi
In reply to this post by Dan Gohman-2
> > We are currently doing this, however I think disabling such
> > optimizations is a much better solution.
>
> An LLVM design goal is that backends should be able to outsmart
> instcombine when necessary, rather than having instcombine be able
> to disable parts of itself in order to avoid foiling the backends.
> Practicality sometimes steers elsewhere of course. Please explain
> why you think suppressing this particular optimization is better;
> it isn't obvious how it would look different in the end.
>

Well, for one thing, our port has no native operation other than 8-bit
so it does not make sense to promote operations to higher precisions.
Eventually all those operations will be lowered and the resulting code
is most likely worse than if it was not promoted in the first place. So
I think it should be at the discretion of port to enable or disable such
optimizations as needed.

A

_______________________________________________
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: disabling combining load/stores in optimizer.

Owen Anderson-2

On Aug 4, 2009, at 12:19 AM, [hidden email] wrote:
> Well, for one thing, our port has no native operation other than 8-bit
> so it does not make sense to promote operations to higher precisions.
> Eventually all those operations will be lowered and the resulting code
> is most likely worse than if it was not promoted in the first place.  
> So
> I think it should be at the discretion of port to enable or disable  
> such
> optimizations as needed.

While that it a valid approach in general, it is completely at odds  
with the approach that the LLVM codebase has taken.  The general LLVM  
philosophy is that all optimizations should be as aggressive as  
possible at whatever they do, and it is then the responsibility of the  
target to lower what the optimizers produce into something legal for  
that machine.

Contravention of that design philosophy in a major portion of the  
optimization suite is unlikely at best, to be honest.

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

smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: disabling combining load/stores in optimizer.

Alireza.Moshtaghi

> > So I think it should be at the discretion of port to enable or
disable

> > such optimizations as needed.
>
> While that it a valid approach in general, it is completely at odds
> with the approach that the LLVM codebase has taken.  The general LLVM
> philosophy is that all optimizations should be as aggressive as
> possible at whatever they do, and it is then the responsibility of the
> target to lower what the optimizers produce into something legal for
> that machine.
>
> Contravention of that design philosophy in a major portion of the
> optimization suite is unlikely at best, to be honest.
>

I can see the benefits of this approach at a macro-level, however at
micro-level the impact is visible especially in embedded targets with
limited memory and register resources (such as pic16)
We see the impact not only wrto code quality but also compile time (to
recover the damage that the optimizer has done). The other problem is
that our port never seem to be stable because as such generic
optimizations get added, something new will break in our port and as
more and more higher end targets are being ported to llvm I expect more
and more optimizations be added that are at odds with our port.
That is why we are asking for a way to at least have some control on
such optimizations.

A.

_______________________________________________
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: disabling combining load/stores in optimizer.

Chris Lattner-2

On Aug 4, 2009, at 9:51 AM, [hidden email] wrote:

>
>>> So I think it should be at the discretion of port to enable or
> disable
>>> such optimizations as needed.
>>
>> While that it a valid approach in general, it is completely at odds
>> with the approach that the LLVM codebase has taken.  The general LLVM
>> philosophy is that all optimizations should be as aggressive as
>> possible at whatever they do, and it is then the responsibility of  
>> the
>> target to lower what the optimizers produce into something legal for
>> that machine.
>>
>> Contravention of that design philosophy in a major portion of the
>> optimization suite is unlikely at best, to be honest.
>>
>
> I can see the benefits of this approach at a macro-level, however at
> micro-level the impact is visible especially in embedded targets with
> limited memory and register resources (such as pic16)

Is this actually causing a performance problem in practice?  If so,  
please show the generated and desired code for a tiny testcase.  
Instead of talking theory, please give an example.

-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: disabling combining load/stores in optimizer.

dag-7
On Tuesday 04 August 2009 12:06, Chris Lattner wrote:

> > I can see the benefits of this approach at a macro-level, however at
> > micro-level the impact is visible especially in embedded targets with
> > limited memory and register resources (such as pic16)
>
> Is this actually causing a performance problem in practice?  If so,
> please show the generated and desired code for a tiny testcase.
> Instead of talking theory, please give an example.

Obviously I don't have a PIC16 example, but we've seen many cases in our
own optimizer where we've had to throttle things, especially for register
pressure.  Sometimes the backend really can't recover because there isn't
enough information to do so.

Generally I abhor throttles.  But sometimes they are necessary because the
earlier passes have the right information to make the decisions.

                             -Dave
_______________________________________________
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: disabling combining load/stores in optimizer.

dag-7
In reply to this post by Alireza.Moshtaghi
On Tuesday 04 August 2009 11:51, [hidden email] wrote:

> recover the damage that the optimizer has done). The other problem is
> that our port never seem to be stable because as such generic
> optimizations get added, something new will break in our port and as
> more and more higher end targets are being ported to llvm I expect more
> and more optimizations be added that are at odds with our port.

Well, this part is on you.  AFAIK, the only PIC16 tests in the LLVM testsuite
were generated by others.  It's up to you to put tests in the testbase that
people can run.  We can't anticipate the affects of choices on your port if
your port isn't part of the regular testing regime.

                               -Dave
_______________________________________________
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: disabling combining load/stores in optimizer.

Alireza.Moshtaghi
In reply to this post by Chris Lattner-2
>
> Is this actually causing a performance problem in practice?  If so,
> please show the generated and desired code for a tiny testcase.

Not anymore; the performance problem has been addressed. Though, there
are other examples of this sort which do not really relate to the
subject of this thread so I would like to discuss them at a different
time.

Thanks for the link to the other thread:
"Adding legal integer sizes to TargetData"

Cheers,
Ali.


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