search for: m_rematerializ

...nd doesn't use AliasAnalysis information, but I > think it could be reasonably generalized to use the new > MachineMemOperand information to be less target-dependent and to > make at least AliasAnalysis::pointsToConstantMemory queries. OK, I will have a look. I assume the reference to M_REMATERIALIZABLE in the comment for it should really be TID::Rematerializable? I also noticed that the documentation for TargetInstrDesc::isRematerializable() says "This flag is deprecated, please don't use it anymore" -- could you explain what replaces it? Stefanus -- Stefanus Du Toit &...

...iasAnalysis information, but I >> think it could be reasonably generalized to use the new >> MachineMemOperand information to be less target-dependent and to >> make at least AliasAnalysis::pointsToConstantMemory queries. > > OK, I will have a look. I assume the reference to M_REMATERIALIZABLE > in the comment for it should really be TID::Rematerializable? I also > noticed that the documentation for > TargetInstrDesc::isRematerializable() says "This flag is deprecated, > please don't use it anymore" -- could you explain what replaces it? I think the idea is...

On Jul 21, 2008, at 3:51 PM, Stefanus Du Toit wrote: > Our frontend can guarantee that loads from globals are > rematerializable and do not alias with any stores in any function in > the given module. We'd like the optimization passes (and ideally the > register allocator as well) to be able to use this fact. The globals > are not constant "forever" but are constant

Our frontend can guarantee that loads from globals are rematerializable and do not alias with any stores in any function in the given module. We'd like the optimization passes (and ideally the register allocator as well) to be able to use this fact. The globals are not constant "forever" but are constant during the calling of any given function in the module. There seem to