[llvm-commits] [PATCH] Disable ARM partial flag dependency optimization at -Oz

Quentin Colombet qcolombet at apple.com
Tue Dec 18 13:37:21 PST 2012


On Dec 18, 2012, at 1:28 PM, Jim Grosbach <grosbach at apple.com> wrote:

> LGTM!
> 
> This should work even for the combination of muddles Renato mentions, as we're re-initializing the value for each MachineFunction we process.

Yes, it should!

Renato, is it ok for you?

-Quentin

> 
> -Jim
> 
> On Dec 18, 2012, at 1:22 PM, Quentin Colombet <qcolombet at apple.com> wrote:
> 
>> Hi,
>> 
>> Thanks for the reviews.
>> 
>> I'd like Jim's idea about caching the information in a local class variable.
>> I've updated the patch accordingly.
>> 
>> New patch attached.
>> 
>> -Quentin
>> 
>> <Thumb2SizeReduction-Oz.patch>
>> 
>> On Dec 18, 2012, at 1:00 PM, Renato Golin <rengolin at systemcall.org> wrote:
>> 
>>> On 18 December 2012 20:18, Jim Grosbach <grosbach at apple.com> wrote:
>>>> The command line options aren't really available here, and we'd have to check for a function-local override anyway, so I don't think that'll work out.
>>> 
>>> True, I forgot about that.
>>> 
>>> 
>>>> Is there concern here the potential compile time impact? Accessing the attribute list should be pretty quick (a couple of pointer indirections and a bit mask).
>>> 
>>> Mainly, yes, but I agree it's not a big problem.
>>> 
>>> 
>>>> If we want, we could cache the value locally in the size reduction pass as a local class ivar and initialize it at the start of runOnMachineFunction(). That would make the access a single pointer indirection off the 'this' pointer for the pass.
>>> 
>>> If that pass would only run on a single module, that'd make sense. But
>>> if you could run it (opt) on a collation of different modules,
>>> possibly compiled with different flags, than I'd think you'd need the
>>> full check.
>>> 
>>> I agree that the lookup is cheap, sorry for having over-complicated things. ;)
>>> 
>>> LGTM.
>>> 
>>> cheers,
>>> --renato
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20121218/b5eba1de/attachment.html>


More information about the llvm-commits mailing list