[LLVMdev] ARM Jump table pcrelative relaxation in clang / llc

[Eric Bentura]

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 at 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 at gmail.com>:
>
>> On 7 July 2015 at 06:06, Eric Bentura <ebentura at 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.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150713/c8ba8b5c/attachment.html>