This is an archive of the discontinued LLVM Phabricator instance.

Add ARM big endian Target (armeb, thumbeb)
ClosedPublic

Authored by cpirker on Mar 17 2014, 7:20 AM.

Details

Reviewers
cpirker
Summary

Hi all,

This patch adds a target machine class for little and big endian ARM.
This includes a modification to the data layout string.
(A corresponding target description has been committed to cfe-commits D3096.)
Please review.

Thanks,
Christian

Diff Detail

Event Timeline

Hi Christian,

I only took a small look at the code so fat, but there were some actual code-changes there so we probably want some tests for them. (those fixups and the ARMISelLowering modifications in particular).

Cheers.

Tim.

lib/Target/ARM/MCTargetDesc/ARMAsmBackend.cpp
648

Why does FK_Data_1 have 2 bytes fixup? If it's not a straight typo, it might be pointing at a bigger abuse in existing code.

I'm just reviewing round the edges i.e. do the target names look sensible and seem to mean the right things.

I'd like to see some tests that:

  1. The new triples produce objects that declare big-endianness - and, now that it's relevant, that the old triples produce objects that declare little-endianness. Something like test/MC/Mips/elf_basic.s, perhaps.
  2. The new triples produce the right subtarget features (re my inline comments).

Do we have such tests on the AArch64 side? I didn't see any last time I looked.

lib/Target/ARM/MCTargetDesc/ARMMCTargetDesc.cpp
96

Oops, bad numbers

100

Oops, bad numbers

cpirker updated this revision to Unknown Object (????).Mar 19 2014, 5:50 AM

Hi Bernie,

I fixed the bad numbers in "lib/Target/ARM/MCTargetDesc/ARMMCTargetDesc.cpp".

Thanks,
Christian

Hi Tim,

This function returns the full instruction size of the fixed-up
instruction, and is not the number of bytes to fixup.
It will be used in the next context below (line 700) to calculate the
index of the changed byte.

Thanks,
Christian

Hi Christian,

This function returns the full instruction size of the fixed-up instruction,
and is not the number of bytes to fixup.

Ok, that brings up two questions:

Did you look into using the DataSize variable? Perhaps more than one instruction ends up in the same block, in which case it wouldn't work. An explanation in comments would be good if so.

What makes you think that FK_Data_1 ends up attached to an instruction needing a 2-byte fixup? At the very least this needs commenting and tests (like everything else) since it's a surprising fact.

Cheers.

Tim.

lib/Target/ARM/ARMTargetMachine.h
171

Are these extra classes needed for some weird magic hidden elsewhere? Because they look fairly cluttered for the sake of one parameter in a constructor.

lib/Target/ARM/MCTargetDesc/ARMAsmBackend.cpp
719

Identifiers beginning with an underscore and a capital letter are reserved in C++. Using them is undefined behaviour.

790

"Thumble" looks rather like an actual word, and "Thumbbe" like a 17th century typo. I'd probably capitalise the BE/LE.

cpirker updated this revision to Unknown Object (????).Mar 20 2014, 12:50 PM

Hi Tim,

The DataSize is not useful for me, because it is the byte size of the whole block (function).

You are right, that FK_Data_1 should not need 2-byte fixup. I was distracted by the case with ARM::fixup_arm_thumb_bcc, ARM::fixup_arm_thumb_cp, and ARM::fixup_thumb_adr_pcrel_10.
I changed the case structure in this differential revision.

Thanks,
Christian

Hi Christian,

Ah, I see. Possibly not always the whole function, but certainly not just one instruction. Fair enough, it does seem fairly useless.

Did you notice my other comments (they were inline in Phabricator, at the end of my message on the list)? The tests and the undefined behaviour in particular will need sorting before this can be committed.

I'm very sorry if you did, and are just updating the patch as you go; I just thought it best to clarify what was going on so we weren't both waiting for the other to respond.

Cheers.

Tim.

Hi Christian,

Those numbers look better - so from my side, the only outstanding thing is testing.

cpirker updated this revision to Unknown Object (????).Mar 27 2014, 11:24 AM

Hi Bernie,

I removed the update of "lib/Target/ARM/ARMISelLowering.cpp" from this patch, because it will be updated separate (patch D3193).

In "lib/Target/ARM/MCTargetDesc/ARMAsmBackend.cpp":

  • added MCFixupKindInfo for little and big endian separate
  • renamed the function "getFixupKindFullInstrSizeBytes" to "getFixupKindContainerSizeBytes"
  • rewrote the function for better understanding

I also updated test files for the fixup handling.

Thanks,
Christian

I committed this patch as r205007.

lib/Target/ARM/MCTargetDesc/ARMAsmBackend.cpp
648

This function returns the full instruction size of the fixed-up instruction, and is not the number of bytes to fixup.
It will be used in the next context below (line 700) to calculate the index of the changed byte.

Hi Christian,

I committed this patch as r205007.

Please don't do that. As far as I can see no-one has said they look
good to commit. The general policy is that if you thought a patch was
worth reviewing, that's not going to change over time so you should
wait until someone says it's OK.

And in fact you've not addressed my comments (even by telling me why
you're right and I'm wrong). They're on the Phabricator issue, but:

+ (ARMTargetMachine.h:170): Are these extra classes needed for some
weird magic hidden elsewhere? Because they look fairly cluttered for
the sake of one parameter in a constructor.
+ (ARMAsmBackend.cpp:719): Identifiers beginning with an underscore
and a capital letter are reserved in C++. Using them is undefined
behaviour.
+ "(ARMAsmBackend.cpp:790): Thumble" looks rather like an actual word,
and "Thumbbe" like a 17th century typo. I'd probably capitalise the
BE/LE.

Cheers.

Tim.

Hi Christian,

Two more issues I've spotted while looking at the diff:

I think the LLVM-side testing is still insufficient. As far as I can tell, we could randomise your new getFixupKindContainerSizeBytes function with no adverse effects on "make check".

lib/Target/ARM/MCTargetDesc/ARMAsmBackend.cpp
105

I also suspect this extra table isn't needed. ARM doesn't make use of the actual offset & size entries, leaving only a cosmetic effect on some of the comments output by llvm-mc.

It also has incorrect entries, even if it should exist (e.g. fixup_t2_movt_hi16 -- the 'i' bit, beyond 20, is affected by the fixup).

Hi Tim,

I am sorry that I committed so fast before I got a definitive OK.

Please see my comments without reply below.
What do you think, should I start a new patch or revert the whole commit?

Thanks,
Christian

Hi Tim,

The comment at line "ARMAsmBackend.cpp:719" is committed in r205215.
The comment at line "ARMAsmBackend.cpp:790" is patched and committed in D3228.

There is no explicit test case for the getFixupKindContainerSizeBytes, but e.g. for function calls this function is relevant and implicit test cases are available.

Thanks,
Christian

lib/Target/ARM/MCTargetDesc/ARMAsmBackend.cpp
105

This table has just been cloned for consistency with the little endian target with corresponding functionality for the big endian target.

Hi Christian,

There is no explicit test case for the getFixupKindContainerSizeBytes, but e.g. for function calls this function is relevant and implicit test cases are available.

This was actually my biggest concern with the patch. The names irked
me, but I could have lived with them. The undefined behaviour was
technically wrong but realistically going to be OK.

But I really would like to see testing of this relaxation code. I've
done an actual test where I mangle the values returned by that
function and no tests break. That's really not a good situation to be
in.

Cheers.

Tim.

cpirker accepted this revision.May 20 2014, 2:37 AM
cpirker added a reviewer: cpirker.

Hi All,

I already committed this patch as rL205007.
There is also an additional patch (D3827, committed as rL209200) with additional test files for ARM fixups.

Thanks,
Christian

This revision is now accepted and ready to land.May 20 2014, 2:37 AM
cpirker closed this revision.May 20 2014, 2:38 AM