[clang] [RISCV][NO-MERGE] Discussions on passing tuning features from the Clang driver (PR #162716)
Sam Elliott via cfe-commits
cfe-commits at lists.llvm.org
Thu Oct 9 13:30:47 PDT 2025
lenary wrote:
Thank you for writing this up, and presenting something concrete.
I became convinced on the call that we cannot disallow disabling features, even though it would make our lives easier, and we probably need to be ready for dependencies between tune features, even though we don't have them today.
> Without any special handling, subtracting features with LLVM's current feature string design can be tricky (e.g. -foo,+foo will still give you foo but not when you write +foo,-foo)
To dive into your mention of "Without special handling": We spent quite a lot of time/energy creating RISCVISAInfo for handling `-march` parsing, I think we should expect to do something similar (but less complex!) for handling `-mtune` parsing, rather than just writing `string.split(...)`. This means we could disallow enabling and disabling the same tune feature in a string, and maybe track conflicts a bit better, to make things easier for the user?
The Arm syntax for mcpu/march `(base)[\+(no)?(featurename)]*` when written as a regex, where the presence of "no" means disable, and `+` is just delimiter. This might be clearer than adding meaning to `+` vs `-`, but I don't hold this opinion strongly. Arm does (almost?) no conflict tracking of their `-march`/`-mcpu` strings, which is IMO part of the reason their situation is complex.
In a bit more detail about may be the right way to do what i'm calling "conflict tracking":
- Parse set of explicitly requested features
- Parse set of explicitly rejected features
- Overlaps between `requested` and `rejected` generate errors
- Calculate implied enabled and disabled features from `requested` and `rejected` (separately).
- Overlaps between `implied_disabled` and `requested` or `implied_enabled` and `rejected` likely generate warnings (maybe errors)
- Calculate final set of enabled/disabled features for passing down to backend.
https://github.com/llvm/llvm-project/pull/162716
More information about the cfe-commits
mailing list