As far as during lto bitcode fileas are used as linker input, the main way to get RISCV subtarget is taken extensions from target-features from functions attributes. Adding processing these attributes during creating TargetMachine in lto backend.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Target features in a function must not leak outside a function. They are per-function for a reason, and are distinct from those for the TargetMachine (but default to that). If you break that then you break IFUNCs.
Target features in a function must not leak outside a function.
All target extensions are placed there and there is already such usage in https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/RISCV/RISCVTargetMachine.cpp#L127. Where should I get extensions information in bitcode file from?
Unfortuantely, I can't find now the comment in code, but I exactly remember the comment that target features for linker in taken from bitcode functions attributes + if -mattr is provided is taken from there also.
I agree with @jrtc27 that this patch is fundamentally flawed. A function may get different attributes (usually extra ones) from the module due to Function Multi Versioning features (GNU function attributes target/target_version/target_clones).
These functions are dispatched at run-time. It is not correct to assume that the mere presence of a function with extra attributes changes the requirement of the module.
It is not correct to assume that the mere presence of a function with extra attributes changes the requirement of the module.
So could you please clarify what should be used to provide target extensions to linker in case of bitcode files? I saw a comment that using function attributes is the preferable way and I provided the link to code that they are used in `const RISCVSubtarget *
RISCVTargetMachine::getSubtargetImpl`
I'm ready to make fix, butI want to understand what is the right way. May be use some other attribute connected with module or something like this?