On 07/14/2011 09:43 AM, Bernd Schmidt wrote:
> (Although now I wonder if we could instead use one of the speculative
> load instructions? There's one that sets the NaT bit if the load would
> fault, isn't there? It's been so long I can't remember.)
We could, but we also have to insert a check load to match.
It gets very difficult to tell when it's worth it.
Your example
(p7) br.cond.dptk .L5
ld8 r15 = [r14]
becomes
ld8.sa r15 = [r14] // speculative advanced load
(p7) br.cond.dptk .L5
ld8.c.clr r15 = [r14] // checked load (clear ALAT)
Note that the speculative load can arbitrarily fail (e.g. tlb miss)
and that the checked load can also arbitrarily re-issue the load.
Note that one can't split "ld8 r14 = [r14]" without additional
register allocation, because the address needs to remain live
until the check.
>> It does raise the question of whether we ought to completely
>> change the way we represent the pairing of LTOFFX/LDXMOV
>> relocations.
>
> This I can't answer since I don't know the definition of these.
These are markers for linker relaxation. If the symbol is
within range,
addl x = @ltoffx(foo), gp
...
ld8.mov y = [x], foo // .mov adds the LDXMOV reloc vs foo to ld8 insn
will be relaxed to
nop
...
addl y = @gprel(foo), gp
The constraint in using the relocations is that every ldxmov
insn must be fed by an ltoffx reloc with the same symbol, and
that an ltoffx reloc cannot feed any other insn. That allows
us, at link time, to not consider data flow, merely assert
that if foo is relaxed anywhere, it's relaxed everywhere.
r~
