This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790
Details
- Reviewers
courbet bollu - Commits
- rGab11b9188d75: [Alignment][NFC] Remove AllocaInst::setAlignment(unsigned)
rPLO373207: [Alignment][NFC] Remove AllocaInst::setAlignment(unsigned)
rL373207: [Alignment][NFC] Remove AllocaInst::setAlignment(unsigned)
rC373207: [Alignment][NFC] Remove AllocaInst::setAlignment(unsigned)
Diff Detail
- Repository
- rL LLVM
Event Timeline
llvm/trunk/lib/Target/AArch64/AArch64StackTagging.cpp | ||
---|---|---|
65 | Can't the Align ctor be constexpr? Will this result in a Log2 call at runtime? |
llvm/trunk/lib/Target/AArch64/AArch64StackTagging.cpp | ||
---|---|---|
65 | The implementation of Log2 is quite complex and depends on the implementation of countLeadingZeros. I could solve this issue by introducing a LogAlign() function returning an Align. This function could be constexpr. What do you think? Is it worth the additional complexity? |
llvm/trunk/lib/Target/AArch64/AArch64StackTagging.cpp | ||
---|---|---|
65 | Since there won't a global ctor at -O2 or higher it probably doesn't matter. I'm not sure if there have been any of these cases yet, but I would think that having a LogAlign/Align::fromLog()/etc. might still be useful for some cases where you get the alignment as log2 instead of in bytes? |
Can't the Align ctor be constexpr? Will this result in a Log2 call at runtime?