[PATCH] D61419: Support FNeg ConstantExpr folding

Cameron McInally via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri May 3 07:43:44 PDT 2019


cameron.mcinally marked an inline comment as done.
cameron.mcinally added inline comments.


================
Comment at: llvm/test/CodeGen/X86/fp-fold.ll:226-242
+
+define float @fneg_undef() {
+; ANY-LABEL: fneg_undef:
+; ANY:       # %bb.0:
+; ANY-NEXT:    retq
+  %r = fneg float undef
+  ret float %r
----------------
cameron.mcinally wrote:
> cameron.mcinally wrote:
> > arsenm wrote:
> > > cameron.mcinally wrote:
> > > > arsenm wrote:
> > > > > cameron.mcinally wrote:
> > > > > > arsenm wrote:
> > > > > > > These tests don't really belong in codegen (same for the vector cases).
> > > > > > > 
> > > > > > > Can you also add a test with some weird constant expressions as a source?
> > > > > > > These tests don't really belong in codegen (same for the vector cases).
> > > > > > 
> > > > > > I'm not that familiar with LLVM's testing layout. Where should they go?
> > > > > > 
> > > > > > > Can you also add a test with some weird constant expressions as a source?
> > > > > > 
> > > > > > Do you mean like the `42.0` I see everywhere? Or something more exotic?
> > > > > > 
> > > > > > There are existing tests that exercise NaN, Inf, and undef in place now. Those came for free from the old `FNEG(X)` -> `FSUB(-0.0, X)` work.
> > > > > Looks like test/Analysis/ConstantFolding is probably the right place.
> > > > > 
> > > > > I mean something like a bitcast of a global address, that isa<Constant>, but isn't ConstantFP
> > > > Sorry, my ignorance is showing here...
> > > > 
> > > > > Looks like test/Analysis/ConstantFolding is probably the right place.
> > > > 
> > > > It looks like all the `RUN:` lines in that directory invoke `opt` with a specific pass or general optimization level. I think I need `llc` to trigger the constant folder for this patch. Is that correct? Or am I missing something obvious...
> > > llc should definitely not be needed.
> > > 
> > > I would expect -instsimplify to work.
> > > I would expect -instsimplify to work.
> > 
> > It does not. Not even with -O3.
> > 
> > This is probably a problem with my understanding of Constant Folding. The code I added only folds constants when a new ConstantExpr is created. I don't see any hooks for an `opt` pass to do folding on the fly though. I'll keep digging to see if I can find my problem...
> > 
> > Or maybe I should just be writing more complex tests that regenerate the FNeg after one of its operands are optimized. I'm not sure...
> > I would expect ` to work
> 
> Ah, ok. So the `instsimplify` pass does it's own folding apart from ConstantExpr. That code will need updating too...
Bah! Apologies, Matt. You were right all along. `SimplifyFNegInst(...)` in `InstructionSimplify.cpp` calls `ConstantFoldUnaryOpOperand(...)`, which eventually ends up in `ConstantExpr::get(...)`. So testing with `-instsimplify` is enough to exercise these new folds.

I'll remove these tests since they're already covered in `Analysis/ConstantFolding/fneg-instcombine.ll`.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D61419/new/

https://reviews.llvm.org/D61419





More information about the llvm-commits mailing list