LOAD_CONST codegen should use llvm::ConstantStruct

[GoogleCodeExporter]

Right now (as of r650), the LLVM IR for "def foo(): return 7" looks 
something like this:

line_start:     ; preds = %continue_entry
    %50 = load i32* getelementptr (%struct._object* inttoptr (i64 
145752472 to
%struct._object*), i32 0, i32 0), align 8       ; <i32> [#uses=1]
    %51 = add i32 %50, 1        ; <i32> [#uses=1]
    store i32 %51, i32* inttoptr (i32 145752472 to i32*), align 8
    store %struct._object* inttoptr (i64 145752472 to %struct._object*),
%struct._object** %stack_bottom
    %f_iblock = getelementptr %struct._frame* %frame, i32 0, i32 19     
; <i8*>
[#uses=1]
    br label %unwind_loop_header

All those inttoptr operations hide data from LLVM. Rather than using 
inttoptr, we should use llvm::ConstantStruct to still keep them as 
constants, but allow better optimization (constant propagation of struct 
members, etc). See r650 for the code that needs to be changed to 
implement this.

Original issue reported on code.google.com by collinw on 17 Jun 2009 at 5:38

[GoogleCodeExporter]

Copied from the previous issue 42:

The biggest wins from embedding consts directly would come from letting
LLVM's const-propagation passes work over them. For example, if we see the code
"1+a", we currently turn that into an indirect call to
"1"->ob_type->tp_as_number->nb_add(1, a). Exposing the whole definition of "1" 
to
LLVM would let it inline that to the direct call int_add(1, a). We'll have to
clang-compile quite a bit more before it can actually do that, but the 
LOAD_CONST
improvement should be a step toward that.

The general idea for this is to make each Python CONST into an LLVM 
GlobalVariable,
mark it constant, and copy the actual value, transitively, into the initializer.
Unfortunately, if we mark the whole thing constant, we can't do things like 
update
the refcount. Chris Lattner said we should write an AliasAnalysis with
pointsToConstantMemory() defined to take care of this. I haven't double-checked 
that
this actually lets SCCP propagate the initial value places, but Chris is usually
right. :)

Original comment by jyass...@gmail.com on 17 Jun 2009 at 6:09

[GoogleCodeExporter]

r812 added support for mirroring Python objects into LLVM GlobalVariables. Now 
we 
just need the AA pass.

Original comment by collinw on 28 Aug 2009 at 10:31

• Changed state: Started
• Added labels: Release-2009Q3
• Removed labels: StarterProject

[GoogleCodeExporter]

The AA modifications landed in r825. Jeffrey, please reopen if needed.

Original comment by collinw on 24 Sep 2009 at 4:03

• Changed state: Fixed