[PATCH] D85614: [TRE] Reland: allow TRE for non-capturing calls.
Alexey Lapshin via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed Oct 21 09:41:30 PDT 2020
avl added inline comments.
================
Comment at: llvm/lib/Transforms/Scalar/TailRecursionElimination.cpp:610
+ CI->getArgOperand(OpndIdx),
+ /*SrcAlign*/ Alignment, Size);
+}
----------------
avl wrote:
> efriedma wrote:
> > I think you need to be more careful with alignment here: it's UB if you specify alignment higher than the actual alignment of the value. For byval arguments with the alignment set, the alignment is exactly that.
> >
> > For byval arguments where the alignment attribute is missing, probably fine to just refuse to do TRE. It's an edge case which shouldn't really come up in practice.
> > I think you need to be more careful with alignment here: it's UB if you specify alignment higher than the actual alignment of the value. For byval arguments with the alignment set, the alignment is exactly that.
> >
> so, instead of this:
>
> Align Alignment(DL.getPrefTypeAlignment(AggTy));
> Alignment = max(Alignment, MaybeAlign(CI->getParamAlign(OpndIdx)));
>
> I need to do just this :
>
> Align Alignment(DL.getPrefTypeAlignment(AggTy));
>
> right?
>
> > For byval arguments where the alignment attribute is missing, probably fine to just refuse to do TRE. It's an edge case which shouldn't really come up in practice.
>
> If alignment attribute is missing would it be OK to use Align(1) ?
i.e. both above conditions would look like this:
```
Align StackSlotAlignment(max(1, MaybeAlign(CI->getParamAlign(OpndIdx))));
Align FinalAlignment(min(DL.getPrefTypeAlignment(AggTy), StackSlotAlignment));
```
would it be correct?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D85614/new/
https://reviews.llvm.org/D85614
More information about the llvm-commits
mailing list