This is an archive of the discontinued LLVM Phabricator instance.

[JITLink][AArch32] Fixes for initial AArc32 backend
ClosedPublic

Authored by Eymay on Aug 9 2023, 12:05 PM.

Details

Summary
  • Fix masking error in Thumb_Jump24
  • Fix halfword comparisons in asserts
  • Add Data_Pointer32 to getEdgeKindName

Diff Detail

Event Timeline

Eymay created this revision.Aug 9 2023, 12:05 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 9 2023, 12:05 PM
Herald added a subscriber: hiraditya. · View Herald Transcript
Eymay requested review of this revision.Aug 9 2023, 12:05 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 9 2023, 12:05 PM
Eymay edited the summary of this revision. (Show Details)Aug 9 2023, 12:10 PM

Thanks, good catches! I will double-check the conditional bit change and let you know.

sgraenitz accepted this revision.Sep 4 2023, 5:13 AM
sgraenitz added a subscriber: peter.smith.

Ok, I finally double-checked it and you are right. Bit 12 must be set and not clear! Can we rename the field to LoBitUnconditional and change the condition into if (!(R.Lo & FixupInfo<Thumb_Jump24>::LoBitUnconditional))?

Additionally, I am afraid there is more to fix here. The docs say:

There is one relocation (R_ARM_CALL) for unconditional function call instructions (BLX and BL with the condition field set to 0xe), and one for jump instructions (R_ARM_JUMP24). [...] Conditional function call instructions (BL<cond>) must be relocated using R_ARM_JUMP24.

I assume the same holds for the respective Thumb instructions? (Do you know @peter.smith?) So, the Thumb_Jump24 relocation is the one that supports conditional branches and Thumb_Call is the one that should have this check :) I leave it to you whether or not to implement this now. We can also do it later and for now only rename the field and fix the condition. Everything else is fine. Thanks for working on this!

This revision is now accepted and ready to land.Sep 4 2023, 5:13 AM

So, the Thumb_Jump24 relocation is the one that supports conditional branches and Thumb_Call is the one that should have this check

Just now I see that this is the bit that sets NoBlx for Thumb_Call and there is nothing to check here! We can simply remove the entire LoBitConditional check including the FixupInfo field :)

Ok, I finally double-checked it and you are right. Bit 12 must be set and not clear! Can we rename the field to LoBitUnconditional and change the condition into if (!(R.Lo & FixupInfo<Thumb_Jump24>::LoBitUnconditional))?

Additionally, I am afraid there is more to fix here. The docs say:

There is one relocation (R_ARM_CALL) for unconditional function call instructions (BLX and BL with the condition field set to 0xe), and one for jump instructions (R_ARM_JUMP24). [...] Conditional function call instructions (BL<cond>) must be relocated using R_ARM_JUMP24.

I assume the same holds for the respective Thumb instructions? (Do you know @peter.smith?) So, the Thumb_Jump24 relocation is the one that supports conditional branches and Thumb_Call is the one that should have this check :) I leave it to you whether or not to implement this now. We can also do it later and for now only rename the field and fix the condition. Everything else is fine. Thanks for working on this!

Thumb (2) has some similarities and some differences. Like Arm there are two relocations R_ARM_THM_JUMP24 for B and a R_ARM_THM_CALL (BL and BLX). However in Thumb state no instructions are conditional they are made conditional by an IT block. So you can have something like:

        .text
        .thumb
        it eq
        bleq foo // R_ARM_THM_CALL

        .arm
        .type foo, %function
        .balign 4
foo:
        bx lr

Which at link time will end up as:

00008000 <$t.0>:
    8000: bf08          it      eq
    8002: f000 e802     blxeq   0x8008 <foo>            @ imm = #0x4
    8006: 0000          movs    r0, r0

00008008 <foo>:
    8008: e12fff1e      bx      lr

So in Thumb state the conditional bl can use the R_ARM_THM_CALL. Which it can't do in Arm state. I would recommend not generating a conditional BL in Arm state if possible as it means that if interworking is needed a full veneer/thunk/stub (whatever it is called in the tool) is needed.

Eymay updated this revision to Diff 555994.Sep 6 2023, 2:47 AM

Removed unconditional check and combined commits into one.

Eymay updated this revision to Diff 555997.Sep 6 2023, 2:55 AM

included both of the unconditional checks

This revision was landed with ongoing or failed builds.Sep 6 2023, 4:10 AM
This revision was automatically updated to reflect the committed changes.