jhuber6 wrote: > > I think there's some precedent from both vendors to treat missing > > attributes as a more generic target. > > It sounds more like a bug than a feature to me. > > The major difference between "you get sm_xx by default" and this "you get > generic by default" is that With specific sm_XX, I can override it both ways > -- I wan enable/disable it if I need to regardless of how it was specified > before my overriding options. > > With the magic unnameable 'generic' target, I can only disable it by > specifying it, but there's no way to enable it once a preceding option names > some specific architecture. > > It makes little difference where you control complete build, but that is not > the case for all builds. E.g. Tensorflow builds with bazel and the end user > does not have access to whatever compiler flags global build rules may set. > So if you want to build for generic GPU target, you will have to jump through > way more hoops than is reasonable, as opposed to specifying a few overriding > options you're interested in. > > I'm fine with defaulting to such generic target, but I do believe we need to > handle it the same way as specific targets.
We could make the driver require some special argument, but the question is how that should be reflected in the LLVM-IR. Right now if you specify `target-cpu` you get `target-cpu` attributes, which is what we don't want. The standard behavior on all other targets is to ignore target-dependent attributes when `-march` or `-mcpu` isn't set, which is exactly what we want here. On the driver level we could hide this behind `-march=generic` if that's important, but I think inside of `clang` it should just be if it's missing as that's the standard handling. https://github.com/llvm/llvm-project/pull/79873 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
