[LLVMdev] [PATCH] - Union types, replaceUsesOfWithOnConstant

Chris Lattner clattner at apple.com
Wed Feb 17 13:38:33 PST 2010


On Feb 17, 2010, at 12:37 PM, Talin wrote:

> On Wed, Feb 17, 2010 at 12:05 PM, Chris Lattner <clattner at apple.com> wrote:
> 
> On Feb 16, 2010, at 12:38 PM, Talin wrote:
> 
> > Here's the implementation of ConstantUnion::replaceUsesOfWithOnConstant(). No tests yet :(
> 
> Seems basically ok, please commit.
> 
> I suppose that means that I'll have to send in the info to get commit access then :(

Yep, plz do.


> IS this what is causing this to be broken?
> 
> No no, nothing's broken. I just wanted to write some tests for the replaceAllUsesOf case, and wondered if there was an existing test to use as a model. 

I'm pointing out that the test doesn't work with mainline, and was hoping that your patch fixes it.

> 
> $ cat t.ll
> @union1 = constant union { i32*, i8 } { i32* @G }
> @G = global i32 4
> $ llvm-as <t.ll | llvm-dis
> ; ModuleID = '<stdin>'
> 
> @union1 = constant union { i32*, i8 } undef       ; <union { i32*, i8 }*> [#uses=0]
> @G = global i32 4
> 
> > -- I could also use some advice on what part of the code to work on next (in terms of finishing up union support).
> 
> What is missing?
> 
> Almost everything :) At this point, the only parts of the code that are aware of unions are:
> Derived type definitions (Type.cpp and so on)
> BitReader and BitWriter.
> LLParser.
> Constants.
> There's no code that calculates the offsets of the union fields for example. None of the code generators know about unions yet.
> 
> That's why I was wondering what area to work on next - I'm unfamiliar with the code and could use a few hints :)

Making TargetData's handle it would make sense which will teach various GEP iteration stuff about unions.  After that I'd try sending various union cases through the code generator to expose the obvious issues there.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100217/d4f071b7/attachment.html>


More information about the llvm-dev mailing list