[llvm-commits] Patch: new backend for Hexagon processor

[Arnold Schwaighofer]

> As Jakob pointed out to me, the core problem is that the current
> register scavenger implementation will only give you one register; for
> the PowerPC case, and it looks like for your case as well, we might
> really need two registers. In the short term, a reasonable solution
> might be to modify the register scavenger to enable it to return
> multiple registers. This seems to be related to the number of emergency
> spill slots the scavenger reserves (because it "cannot fail"), so there
> might be some downside to this. We would have to add some
> target-dependent callback to tell the register scavenger how many slots
> to reserve (the default would be 1). Do you think that this is worth
> doing?
>

I started modifying the backend to support 2 scavenged registers only to
end up realizing half way through that in our case we don't need two.

On Hexagon we can get around the requirement for the second register (the
first for storing the predicate, second for a large offset that does not
fit into the spill instruction) by using a constant extended value. A
constant extend value is a value encoded in the instruction stream, taking
up one instruction slot.

{
r10 = memd(fp+##LARGEOFFSET)
}
For us this is the better solution as we want as little as possible spill
code in hot regions.

To support 2 scavenged registers, as you already said, we would need:
* target hook to indicate the maximum number of simultanously live
scavenged registers needed
* support in RegScavenger for more than one registers: instead of state
for one register (ScavangedReg, ScavengedRC, ScavengedRestore) we need
need an array of such states that are handled correctly
* PEI::scavengeFrameVirtualRegs must be adopted to handle more than one
register
* PEI::calculateFrameObjectOffsets needs to handle the reserved scavenger
spill slot frame indexes

- arnold

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum.