[PATCH] D60942: Emit diagnostic if inline asm "n" constraint isn't an immediate
Bill Wendling via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon May 13 23:15:17 PDT 2019
void added a comment.
In D60942#1500749 <https://reviews.llvm.org/D60942#1500749>, @joerg wrote:
> In D60942#1500742 <https://reviews.llvm.org/D60942#1500742>, @void wrote:
>
> > In D60942#1500730 <https://reviews.llvm.org/D60942#1500730>, @joerg wrote:
> >
> > > On the frontend side:
> > >
> > > - __builtin_constant_p is not expanded correctly in EvalConstant.cpp when used as part of codegen for -O0. This means that trivially unreachable branches are emitted (e.g. with a BR with a literal false as condition),
> > > - The constant evaluator has a general problem with overly pessimistic analysis when it comes to possible side effects. Still have to discuss the correct handling with Richard for this.
> >
> >
> > GCC has this to say about `__builtin_constant_p`'s behavior:
> >
> > > A return of 0 does not indicate that the value is not a constant, but merely that GCC cannot prove it is a constant with the specified value of the -O option.
> >
> > When I was modifying our implementation recently, I made it so that if there are no optimizations then we evaluate to `0` in the front-end before code-gen. It might be that those blocks are being emitted, but they should have something like `br i1 false, label %true_bb, label %false_bb` or equivalent.
>
>
> Yes, that's correct. The problem is that with `-O0`, we never run SimplifyCFG, so those conditional branches make it straight to the backend. As discussed with Richard on IRC, the core issue is that for -O0, the IR generation for __builtin_constant_p is different from the constant folding as part of AST/EvalConstant.cpp. The latter is used by EmitIfStmt and friends to decide whether the BBs should be created in first place and currently fails evaluation for bcp.
>
> >> On the backend side:
> >>
> >> - The is_constant intrinsic is lowered too late. The prepare-isel pass it is currently part of is run after the last SimplifyCFG pass, so the now-dead basic blocks are never pruned and therefore the asm statements survive.
> >
> > Is this at `-O0` or all optimization levels?
>
> With `-O0`, the intrinsic is never generated and no SimplifyCFG is run either (see above).
Ah! I understand now. I'll see if there's something I can do to help with this. Could you send me some test cases so that I can test things?
Repository:
rL LLVM
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D60942/new/
https://reviews.llvm.org/D60942
More information about the llvm-commits
mailing list