(original) (raw)

Hi,

I have kept working on this and found the following (as llvm 3.5):

1) In the function MCObjectStreamer::EmitInstruction there is a check for the instruction being relaxable or not:

if (!Assembler.getBackend().mayNeedRelaxation(Inst)) {

EmitInstToData(Inst, STI);

return;

}

At this stage, the instruction as been already selected to be ARM::ADR.

The call to mayNeedRelaxation() resolve to ARMAsmBackend::getRelaxedOpcode().

There is no processing in there for ARM:ADR. I added the following line:

case ARM::ADR: return ARM::t2ADR;

As a result, if relaxation is enabled or bundling is enabled then the instruction is relaxed.

And compilation to object passes.

I am not familiar enough with this to understand why there is a condition to enter the relaxtion step : I had to set manually Assembler.setRelaxAll(true) to get into this step.

2) It seems that Fast instruction selection is enabled by default (even when using -O3). The problem does not appear when not using Fast sel (again used a hack in the code) although the same ADR instruction is selected since the offset to apply to the fixup is small enough.

I am not sure I am on the right track, but as far as I understand:

1)ARM::ADR is not handled by relaxation

2)Relaxtion happens under some condition in the ObjectStreamer that I don't fully understand

What do you think?

Thanks,

Eric

2015-07-13 15:41 GMT+03:00 Eric Bentura <ebentura@gmail.com>:

Hi,
I have kept working on this and found the following (as llvm 3.5):
1) In the function MCObjectStreamer::EmitInstruction there is a check for the instruction being relaxable or not:
if (!Assembler.getBackend().mayNeedRelaxation(Inst)) {
EmitInstToData(Inst, STI);
return;
}
At this stage, the instruction as been already selected to be ARM::ADR.
The call to mayNeed

2015-07-07 18:06 GMT+03:00 Tim Northover <t.p.northover@gmail.com>:
On 7 July 2015 at 06:06, Eric Bentura <ebentura@gmail.com> wrote:
\> I have created a small ll file to reproduce the problem.
\> I used the intrinsic function llvm.arm.space to introduce space between the
\> beginning of the code and the jump table.

It does look like the value in @llvm.arm.space is interpreted
incorrectly if it's bigger than INT\_MAX, but that's well outside its
intended range and could inevitably be used to break ConstantIslands
(the longest ARM immediate branch is 26-bits; no indivisible entity in
.text can be bigger than that). It's probably an unrelated issue.

Also, I know I said the backend should accept any size code, but 2GB
is definitely going to trigger more edge cases than average.

Cheers.

Tim.