[LLVMbugs] [Bug 10368] New: Redesign ConstantExpr's

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Thu Jul 14 23:32:19 PDT 2011


http://llvm.org/bugs/show_bug.cgi?id=10368

           Summary: Redesign ConstantExpr's
           Product: libraries
           Version: 1.0
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Core LLVM classes
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: clattner at apple.com
                CC: llvmbugs at cs.uiuc.edu


We currently allow ConstantExprs occur for any side-effect free LLVM IR
instruction, and use ConstantExpr::get as the primitive constant folding API in
LLVM.

This doesn't make sense for a number of reasons:

a) code generators can't codegen arbitrary constant exprs at arbitrary places,
causing global variable initializers to explode in funny ways if the optimizer
gets creative.  
b) constant expressions like divides canTrap() which is a common source of
bugs.
c) optimizers typically treat constants as cheap or free, but a ConstantExpr
can have arbitrary cost.
d) optimizers try to handle both instructions and constantexprs equally well in
many cases, leading to complexity in PatternMatch.h and to the existence of the
Operator classes, which are gross.
e) we have no way to represent target-specific relocations that don't
conveniently map to ConstantExprs.

Instead, I propose that we implement the following plan:

1. Switch everything off using ConstantExpr::get as constant folding API, onto
the InstSimplify APIs, which are more general and powerful anyway.
2. Move all of the constant folding logic out of ConstantExpr::get into
InstSimplify so that ConstantExpr::get *just* creates them.
3. Remove the canTrap() constant exprs, simplifying the world and cleaning up
tons of stuff.
4. Introduce new ConstantExprs for target specific things that we currently
need like darwin_symbol_difference.
5. Remove various extraneous constantexprs other than GEP and bitcast.
6. Introduce a new ConstantExpr "base_offset" node which takes a constant
pointer and integer and adds them together, returning a new pointer.  Teach the
optimizer to optimize them as well as ConstantExpr GEP's are right now.
7. Remove the gep constantexpr, leaving us with the target specific ones,
bitcast, and base_offset.
8. Profit!

-Chris

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.



More information about the llvm-bugs mailing list