[LLVMdev] First-class aggregate semantics

[Dustin Laurence]

On 01/08/2010 09:32 PM, Nick Lewycky wrote:

> As a small refinement, I recommend:
> 
> %s1 = insertvalue {i32, i32} undef, i32 1, 0
> %s2 = insertvalue {i32, i32} %s1, i32 2, 1

Ah, excellent.  I hadn't found a use for 'undef' yet, but I like that.
I don't like substituting values into a literal with arbitrary values
because, well, it's unlovely.  Saying the values don't matter is much
better.

I don't think there is a place in my lexer that happens to need exactly
that as one or the other members of the token structure always seems to
be a literal, but your example did lead me to use undef for individual
members being replaced in an insertvalue instruction.

> No, there is no copy or move instruction in LLVM. Recall that the text
> format is 1:1 with the in-memory model of the program. A copy
> instruction in the IR would literally mean "go look at my operand
> instead", leading to logic in every optimization that checks for a
> CopyInst and chases the pointer.

My desire to do such things is a direct consequence of my apparently odd
choice to learn the IR by approaching it as a programming language.
While it clearly wasn't intended for it, my first computer had three
registers, only one of which was a mighty sixteen bits wide, so I've
hurt worse before. :-)

That said, the need to parameterize code is too great not to do
something, and since LLVM isn't designed to do it I have been using CPP.
 Doing without even the modest abilities of CPP is simply not to be
thought of.  If I did enough hand-coding it would be well worth writing
a custom preprocessor.

> The astute reader will note that I'm lying again, but it's for your own
> good. ;-) "%x = bitcast i32 %y to i32" is a legal way to copy, but the
> intention behind a BitcastInst is that it is used to change the type.

If I was concerned about my own good I probably wouldn't be hand-coding. :-)

Dustin