AOT code usage restrictions

[Andrew Haley]

On 1/23/26 2:04 AM, Vladimir Kozlov wrote:
> What do you think about this proposal?

I think Options 1 and 2, "AOT code will not be used if CPU features on 
machine for production run does not match" is unlikely to be practical 
for production code because of the enormous variety of machine 
capabilities. So even on a system like AWS, you might not be able to 
move code from Graviton 4 to Graviton 3. Everybody will hate that.

It is very important that our default target be really simple and really 
generic, such as Armv8.0 or x86-64.

GCC's x86-64 default is simply x86-64, which means Opteron of 2003.

GCC's AArch64 default is Armv8.0, with some instructions that are 
available on later ISA versions handled by library stubs. For example, 
the compare-and-swap instructions are callouts. We could do that 
ourselves, or perhaps decide that Armv8.1, which has a full set of 
compare-and-swap instructions, is our baseline.

It's interesting to note that most operating systems and other programs 
people install are compiled with default options that correspond to 
really old machines. I don't think that many people are troubled by 
that. Few people tune compiled code to specific architecture versions, 
except for super-critical tweaked code such as video codecs.

GCC also allows the option "-march=native", which will use every feature 
you've got, and it also allows many named sub-arch options if you know 
the name of the exact target. I don't think we'll want to have hundreds 
of options like GCC, though.

In the end, I think we're just going to have to do Option 3, as GCC 
does. Default to generic, maybe with callouts to stubs in some cases, 
with a command-line option to compile for this native machine.

Andrew.