[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