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

[Evan Cheng]

On Nov 10, 2010, at 6:19 PM, Jakob Stoklund Olesen wrote:

> 
> 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?

Dan?

Evan

> 
>