[JITLink][i386] Avoid 'i386' name clashing with built-in macro

[DimitryAndric]

When compiling llvm on an actual i386 platform, both clang and gcc define a built-in macro i386 to the value 1. This clashes with the llvm::jitlink::i386 namespace:

In file included from llvm/lib/ExecutionEngine/JITLink/ELF_i386.cpp:18:
llvm/include/llvm/ExecutionEngine/JITLink/i386.h:19:24: error: expected '{'
   19 | namespace llvm::jitlink::i386 {
      |                        ^
llvm/include/llvm/ExecutionEngine/JITLink/i386.h:19:26: error: expected unqualified-id
   19 | namespace llvm::jitlink::i386 {
      |                          ^

The macro name 'i386' is obviously a historical bad choice, but since it existed long before llvm, llvm should either rename its namespace, or actively undefine the macro in i386.h (similar to e.g. https://github.com/google/swiftshader/blob/master/third_party/llvm-16.0/Android.bp#L1510).

This particular pull request implements the rename, but is meant to gauge opinions on how to solve this issue.

[jrtc27]

When compiling llvm on an actual i386 platform, both clang and gcc define a built-in macro i386 to the value 1.

* As GNU C/C++. This of course also extends to any third-party code compiled as such that includes this header.

[DimitryAndric]

Since the llvm build system itself explicitly compiles this with -std=c++17, not -std=gnu++17, I think the problem we've encountered in FreeBSD is self-inflicted. :) Then again, for other projects it might be nicer to avoid this identifier, or at the least #undef it if it exists.

[lhames]

I’d be fine renaming this backed to x86 (or x86_32) to avoid the clash. I doubt that there are any explicit references to jitlink::i386 outside llvm-project so I’d expect the fallout to be minimal (beyond a bunch of renames in LLVM itself).

I’m travelling with limited internet access for the next week and a bit, but can check in on this when I get back to my desk.

[lhames]

This should be fixed by b972164 and prior commits.