I see your point. It looks reasonable.
But if the absence of 'base' in TauLdInd arguments is the only reason,
IMO it is easier to get 'base' info from the instruction that defines
address than to get over memopt and other HLO.
(AFAIU read barriers are not being optimized by HLO optimizations.
So It is better to insert them into CFG as late as possible)
we have TauLdInd(address) and CodeSelector selects it to some MOV
instruction.
addrDefInst = address->getDefiningInst()
base = addrDefInst->getSrc(the id of 'base');
Most probably addrDefInst will be ADD instruction. (selected from
LdFieldAddr or smth. similar)
(Same things are being analyzed in cafl - Complex Address Form Loader
pass in codegen. So some code can be reused from it.)
Please pay attention that getDefiningInst can be called only when
CodeSelector finished its work and calculateOpndStatistics was called.
So I'd suggest a dedicated codegen pass for read barrier insertion.
(all above is based on the fact that there is no other arguments for
doing this in HLO)
Simon Chow wrote:
George
Thanks for your suggestion.
IMO, the current information in Inst of TauLdInd is not enough for read
barriers generation.
That's the reason why I tend to implement a new opcode TauLdRef.
For example, there is no ref holding object reference (like 'base' in
TauStRef) in TauLdInd, but it is necessary for read barrier.
Additionally, IMO, not all the 'TauLd' need to be intercepted, my TauLdRef
only represents the ref loading that requires barrier.
Do you think it is reasonable?
Thanks
2008/5/19 George Timoshenko <[EMAIL PROTECTED]>:
Hi.
You are trying to work and solve problems in HLO.
What do you thing on the current write barrier implementation?
WBs appeare only in code selector. HLO knows nothing about them.
Why don't use similar approach and just implement read barriers generation
in CodeSelector?
Doing this you should not care on MemOpt and other HLO stuff.
George.
