[LLVMdev] Possible bug in the ARM backend?

[Roman Levenstein]

Hi Evan,

Thanks for your feedback!

2009/1/7 Evan Cheng <evan.cheng at apple.com>:
>
> On Jan 7, 2009, at 2:48 AM, Roman Levenstein wrote:
>
>
>  As you can see, PrologEpilogInserter has inserted at the beginning
> of the function some code for manipulation of the frame pointer and
> this inserted code uses the LR register.
>  As far as I understand,  ARMRegisterInfo.td should exclude the LR
> register from the set of allocatable registers for functions that
> require frame pointer manipulation.
>  But currently it is not the case, or?
>
> No, LR is not the frame pointer. It's the link register (caller address). It
> should be available as a general purpose register.

OK.

> The bug is elsewhere. It  has to do with kill / dead markers.
>        %LR<def> = LDR <fi#0>, %reg0, 0, 14, %reg0
>        %SP<def> = ADDri %SP<kill>, 4, 14, %reg0, %reg0
>        BX_RET 14, %reg0
> LR is restored here but it's not killed before the end of the block is
> reached.

Hmm. I have no idea about what ARM backend does. My register allocator
just assigns the registers as I explained in my original mail.
Then it lets VirtRegMap.cpp do its job, i.e. it lets it rewrite the
code and replace virtual registers by the assigned physical registers.
You can see the result in the step (3) of my original mail. In my
opinion, it still looks correct. May be this rewriting process does
something wrong?

Then PrologEpilogInserter and some other standard post RA passes are
invoked for the ARM backend. But I have not changed anything there, so
I have no idea what happens.

And, BTW, the instructions you mentioned above are after the
instruction triggering the assertion, which is:
STR %LR<kill>, %R0<kill>, %reg0, 0, 14, %reg0, Mem:ST(4,4) [0x8fc2d68 + 0]

> Should BX_RET use it?

I don't know the semantics of BX_RET on the ARM platform. May be it
uses BX_RET somehow.

BTW, an idea: May be it is easy to trigger exactly the same behaviour
with the linear scan if one does the following:
  - comment out dependency on the coalescer, so that it is not invoked
  - change the allocation order of the GPR register class for ARM, so
that it starts with the LR register.
,
Any ideas how to proceed with the current situation?

-Roman

>  I hope that I provided enough information to explain my problem. I
> also provided my initial analysis, but may be I'm wrong.
>
>  Can someone more knowledgeable in ARM backend and LLVM's register
> allocation framework have a look at it?
>  If it is a bug in the ARM backend, could it be fixed?
>
>  Thanks,
>   Roman
> <bugpoint-reduced-simplified.bc>
>