[PATCH] D122097: [BOLT] AArch64: Emit text objects

[Rafael Auler via Phabricator via llvm-commits]

rafauler accepted this revision.
rafauler added a comment.
This revision is now accepted and ready to land.

Overall LGTM.

The model that BOLT tries to create in memory is one in which every byte in an executable section has an associated BinaryFunction. From the point of view of the processor, an executable section should contain code, and BOLT models all code as the contents of a function.

BOLT deals poorly with data in code: it will mark the function containing data and will avoid processing it. Besides, in X86, it is frequently a bad practice to put data in the code section, as the processor has different caches for instruction and data, and if you put non-instruction bytes in the instruction stream, you will be unnecessarily polluting i-cache.

In AArch64, since it's a RISC processor that absolutely needs to put stuff in the executable sections due to limited range access, I expanded BOLT's IR to consider that a function might have data in code that is easily identifiable via $d symbol markers in the ELF file.

Given this context, an empty function with a constant island (freestanding data in code that is not part of any function) is a curious thing to see. Where is this happening?



================
Comment at: bolt/lib/Passes/Aligner.cpp:177
+    // to at least 8 bytes.
+    if (!BF.size() && BF.hasIslandsInfo()) {
+      const uint16_t Alignment = BF.getConstantIslandAlignment();
----------------
Is this in sync with LongJmp?


================
Comment at: bolt/test/AArch64/text_data.c:17
+
+__attribute__((section(".text"))) const FooPtr arr[] = {exitOk, NULL};
+
----------------
Just curious, how would this ever happen naturally (without forcing the compiler to do so)? If this is a synthetic test, it would be good to have a test that shows the real use case of freestanding data in code. But it's fine if it's not possible (e.g. if this is created as part of a non-C compiler implementing some specific runtime).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D122097/new/

https://reviews.llvm.org/D122097