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
Paths
| Differential D3095
Add ARM big endian Target (armeb, thumbeb) ClosedPublic Authored by cpirker on Mar 17 2014, 7:20 AM.
Details
Diff Detail Event TimelineComment Actions 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.
Comment Actions 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:
Do we have such tests on the AArch64 side? I didn't see any last time I looked.
Comment Actions Hi Bernie, I fixed the bad numbers in "lib/Target/ARM/MCTargetDesc/ARMMCTargetDesc.cpp". Thanks, Comment Actions Hi Tim, This function returns the full instruction size of the fixed-up Thanks, Comment Actions Hi Christian,
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.
Comment Actions 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. Thanks, Comment Actions 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. Comment Actions Hi Christian, Those numbers look better - so from my side, the only outstanding thing is testing. Comment Actions 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":
I also updated test files for the fixup handling. Thanks, Comment Actions I committed this patch as r205007.
Comment Actions Hi Christian,
Please don't do that. As far as I can see no-one has said they look And in fact you've not addressed my comments (even by telling me why + (ARMTargetMachine.h:170): Are these extra classes needed for some Cheers. Tim. Comment Actions 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".
Comment Actions Hi Tim, I am sorry that I committed so fast before I got a definitive OK. Please see my comments without reply below. Thanks, Comment Actions Hi Tim, The comment at line "ARMAsmBackend.cpp:719" is committed in r205215. 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,
Comment Actions Hi Christian,
This was actually my biggest concern with the patch. The names irked But I really would like to see testing of this relaxation code. I've Cheers. Tim. This revision is now accepted and ready to land.May 20 2014, 2:37 AM
Revision Contents
Diff 7880 include/llvm/ADT/Triple.h
lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp
lib/Support/Triple.cpp
lib/Target/ARM/ARMAsmPrinter.cpp
lib/Target/ARM/ARMISelLowering.cpp
lib/Target/ARM/ARMSubtarget.h
lib/Target/ARM/ARMSubtarget.cpp
lib/Target/ARM/ARMTargetMachine.hlib/Target/ARM/ARMTargetMachine.cpp
lib/Target/ARM/AsmParser/ARMAsmParser.cpp
lib/Target/ARM/Disassembler/ARMDisassembler.cpp
lib/Target/ARM/MCTargetDesc/ARMAsmBackend.cpp
lib/Target/ARM/MCTargetDesc/ARMELFObjectWriter.cpp
lib/Target/ARM/MCTargetDesc/ARMMCAsmInfo.h
lib/Target/ARM/MCTargetDesc/ARMMCAsmInfo.cpp
lib/Target/ARM/MCTargetDesc/ARMMCCodeEmitter.cpp
lib/Target/ARM/MCTargetDesc/ARMMCTargetDesc.h
lib/Target/ARM/MCTargetDesc/ARMMCTargetDesc.cpp
lib/Target/ARM/TargetInfo/ARMTargetInfo.cpp
|
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.