Improve llvm-config.h to record which target is configured or not

[joker-eph]

These macro can help guarding some tests and other section of code
which rely on detecting if a particular target is available. This
is common the MLIR codegeneration for GPU targets for example.

[nico]

Before this change,. toggling on or off a target required building fairly few files. Now it's a full rebuild. Any chance we could use a different approach here?

[joker-eph]

Is this a common thing to switch back and forth? Also isn’t ccache good enough cases where one would want to back and forth?

[joker-eph]

Actually: the header change will invalidate ccache

[joker-eph]

Thinking a bit more about this: seems to me that the underlying problem with respect to caching and rebuilding is that the llvm-config.h file is monolithic and every flag adds to the burden.
What about splitting it? We can have a subfolder configs/xxx.h for every flag (or grouping of flags) and the top-level llvm-config.h including all of them.
Then it's a matter of migrating current includes of llvm-config.h to include the specific configs/xxx.h, this should provide the finer grain rebuild we could expect?

[fabianmcg]

That would solve the issue, however, that's a big refactor. How about, just creating llvm-targets.h and moving these flags there?

[joker-eph]

I don't see anything more special about these than any other flags right now though.

[fabianmcg]

You're right, I was just proposing avoiding a bigger refactor as splitting it means going through each include of llvm-config.h and only including the necessary files. I think Targets.h, Version.h, TargetDefault.h, BuildOptions.h would do it.

[nico]

Splitting more would be nice, but doing the smaller thing might be easier.

[nico]

Is this a common thing to switch back and forth?

I do it several times a week at least. I usually only build with host arch, and if I need to enable an additional arch to debug a per-arch thing I turn on that arch. That used to be very quick, and now it isn't. (As you say, it's a full rebuild without any cache hits.)

Maybe it could be a generated header in mlir for gpu targets only? Then it wouldn't affect me at all. Putting it in llvm-config.h just because the file already exists seems a bit weird – half of llvm-config.h are these defines now.

[joker-eph]

I need to enable an additional arch to debug a per-arch thing I turn on that arch

I do this as well, but it hardly a frequent thing that I break another target. But then I don't work on SelectionDAG either (but if I was, I would keep all the targets enabled all the time: better ccache and better incremental rebuild anyway)

Maybe it could be a generated header in mlir for gpu targets only?

Does not make sense to me: this isn't an MLIR settings...

Putting it in llvm-config.h just because the file already exists seems a bit weird

Seems to me like this is the unfortunate design of llvm-config.h...

Please take a look at #71273 !