[llvm-commits] [llvm] r118702 - in /llvm/trunk/lib/CodeGen: SplitKit.cpp SplitKit.h

[Jakob Stoklund Olesen]

On Nov 10, 2010, at 5:52 PM, Evan Cheng wrote:

> 
> On Nov 10, 2010, at 1:08 PM, Jakob Stoklund Olesen wrote:
> 
>> 
>> On Nov 10, 2010, at 12:17 PM, Evan Cheng wrote:
>> 
>>> Are you restricting remat to instructions with no register operands?
>> 
>> No, I allow register operands as much as isTriviallyReMaterializable does, but I never extend live ranges of operands to do so. I require all operands to be live with the same value at the remat location. This check is implemented in LiveRangeEdit::allUsesAvailableAt().
> 
> Ah ok. We can potentially allow more remat by extending live ranges with more analysis. But that's later.

Yes, that is tricky. The extended live range must be useful for more than one remat. Otherwise register pressure stays the same.

>> I wonder if 'isTriviallyReMaterializable' means that the instruction can be rematted anywhere without further checks? If so, I should perhaps be using the basic TID::isRematerializable() flag instead?
> 
> Right. It's only meant for the existing brain dead remat.

I see. X86InstrInfo::isReallyTriviallyReMaterializable in particular has many arbitrary restrictions. I'll look into something more generic.

I would be useful to be able to remat loads that have been hoisted by early optimizations. Is there any way AliasAnalysis can be rigged to provide more information than AA->pointsToConstantMemory?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1929 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20101110/ce8c9994/attachment.bin>