This is in response to recent emails about extending the numbers of available lanes. While that problem went away, this is a more generic approach than what we have at the moment.
I haven't tested it beyond "check-llvm". I'm wondering what you think.
Details
- Reviewers
- None
Diff Detail
- Repository
- rL LLVM
Event Timeline
lib/CodeGen/MIRParser/MIParser.cpp | ||
---|---|---|
548 | This part is not complete. |
- I would be slightly hesitant here, as it complicates code and none of the public targets needs this. We don't even try the "uint64_t" instead of "unsigned" step but instead just make it all complicated right away...
- I would not commit this without careful measurements to ensure that compilers indeed optimize all of this away and we don't have a compiletime impact.
- You probably can use some of the APInt::tcXXX functions to avoid code duplication.
Yeah, there is no need for it right now. I was just curious about this kind of approach.
I can keep this as a patch here in case this issue comes back later.
Can we go ahead and add getHighestLane to the existing class to hide the Log2_32? Maybe getNumLanes as well.
I m working on huge hardware and I need this patch to work. When I tested this for N=128 I am getting error like "Must be a leaf subregister".
include/llvm/MC/LaneBitmask.h | ||
---|---|---|
149 | I think this leaves all the other entries in T as garbage. This could explain the error hameeza is getting. Try changing this to Type T = {}; |
include/llvm/MC/LaneBitmask.h | ||
---|---|---|
149 | Good catch. Btw, feel free to reinstate yourself as a reviewer if you feel so inclined... |
I think this leaves all the other entries in T as garbage. This could explain the error hameeza is getting.
Try changing this to