X86-32-bit testing

Project Infrastructure
1

Some recent changes happened to break building core LLVM code on x86-32 Linux targets (it happened to assume pointers were > 32 bits in size). The specific change that did this is irrelevant here; my question is regarding the ongoing support for 32-bit builds of LLVM; from what I can tell from Buildbot, there aren’t any builders actually testing (or even building) for this target.

If LLVM is going to continue to support 32-bit builds, then having test coverage on 32-bit machines seems essential. (And if it’s not, well, guidance on that front would be welcome too…)

2

I can half answer this. We (Linaro) are running 32 bit bots for Armv7 builds (e.g. Buildbot, we have larger ones too).

I don’t see anything but x86_64 in the buildbot list either. So I assume it is not being built.

I know that some projects have decided to to pay attention to 32 bit at all. MLIR (and hence flang) being examples.

This is beside your point but can you link the specific change? I wonder if it is x86 specific or a part of llvm we happen not to build. If it’s the latter maybe we should be doing so.

3

There are downstream consumers of llvm that still need a x86-32 build (f.ex. Debian still supports i686-compatible CPUs) – so, yes, this is a hole in the test coverage that it would be good to address, rather than an indication that x86-32 is an unsupported platform.

4

Failure: ⚙ D134224 [clang][modules][deps] Report modulemaps describing excluded headers
Fix: ⚙ D134653 [clang][modules] Over-align the `Module` class

If clang::Module is 4-byte aligned by default on 32-bit ARM then I suspect it would fail there just like x86.

5

There is no assert in llvm::PointerIntPair?

6

It is and I am surprised we didn’t see the issue. I will see why that was.

There is according to a comment on ⚙ D134224 [clang][modules][deps] Report modulemaps describing excluded headers.

7

Apologies, my initial test was wrong. It is in fact aligned to 8 bytes on Arm 32 bit.

I seem to remember that struct packing is one place where ABI differences are common, and I agree that a 32 bit x86 buildbot is a good thing to have.

8

32-bit x86 is special in having a 4-byte-aligned (u)int64_t (i.e. long long), perhaps there’s one of those in the class somewhere?

9

In general, there isn’t any central control over what buildbot configurations exist. lab.llvm.org itself is centralized infrastructure, but all the actual builds run on machines maintained by other organizations or individuals. And those organizations control which configs run on their machines. See How To Add Your Build Configuration To LLVM Buildbot Infrastructure — LLVM 16.0.0git documentation . (Some organizations also have buildbots that aren’t connected to lab.llvm.org; Apple runs green.lab.llvm.org, and some organizations have private buildbots.)

If there’s a configuration you think is important, you need to convince someone to maintain it. That probably means finding someone new to run the buildbot; if someone currently running a buildbot cared, there would already be a config.

If someone is interested in maintaining a config, but doesn’t have an appropriate computer/network available, the LLVM Foundation might be able to help with that.