AlexVlx wrote: > An intrinsic seems like the right IR model for CPU recognition, even for > targets that don't specifically need to late-resolve it. That should be much > easier for passes to optimize based on CPU settings than directly emitting > the compiler-rt reference in the frontend. I know that generating IR with > conservative target options and then bumping the target CPU in a pass is > something various people have been interested in, so late optimization is > specifically worth planning for here. > > We do have a theoretical problem with guaranteeing that non-matching code > isn't emitted, because LLVM IR doesn't promise to leave a code sequence like > this alone: > > ``` > %0 = call @llvm.compiler_supports(...) > br i1 %0, label %foo, label %bar > ``` > > LLVM could theoretically complicate this by e.g. introducing a PHI or an > `or`. But that's a general LLVM problem that any lowering would have to deal > with.
The solution we went with here (for our use case) is to just run the predicate expansion pass over pristine Clang generated IR, before any other optimisation. I think that @nikic suggested an alternative based on `callbr`, but that'd be somewhat challenging to represent in SPIRV which is important to us, but then again this could just be an implementation detail for cpu_is gets lowered, I guess? I.e., since we know we're only ever going to deal this early, we could just leave the call in place since we know no optimisation will complicate things, conversely other targets could go with `callbr` etc. https://github.com/llvm/llvm-project/pull/134016 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
