similar to: [LLVMdev] questions about the type system rewrite

Hi James, Sorry I missed this. Please send things to the list, not to me directly. On Jul 20, 2011, at 9:52 PM, james woodyatt wrote: > One thing that springs to mind after reading the <http://nondot.org/sabre/LLVMNotes/TypeSystemRewrite.txt> note is that the vocabulary seems a bit confusing. > >> This argues for terminology along the lines of: >> >> Named

Several people have been proding me to write up my thoughts on how to fix the IR type system for LLVM 3.0. Here are some (fairly stream of conscious) thoughts on the matter: http://nondot.org/sabre/LLVMNotes/TypeSystemRewrite.txt Comments welcome! -Chris

Hey Chris, On Sat, Feb 26, 2011 at 1:25 PM, Chris Lattner <clattner at apple.com> wrote: > Several people have been proding me to write up my thoughts on how to fix the IR  type system for LLVM 3.0.  Here are some (fairly stream of conscious) thoughts on the matter: > http://nondot.org/sabre/LLVMNotes/TypeSystemRewrite.txt Awesome! This is definitely long overdue... Proposal seems

On 26 February 2011 21:25, Chris Lattner <clattner at apple.com> wrote: > Several people have been proding me to write up my thoughts on how to fix the IR  type system for LLVM 3.0.  Here are some (fairly stream of conscious) thoughts on the matter: > http://nondot.org/sabre/LLVMNotes/TypeSystemRewrite.txt Hi Chris, I don't see such a bad problem with PATypeHolder, but I get what

On Sat, Feb 26, 2011 at 10:25 PM, Chris Lattner <clattner at apple.com> wrote: > Several people have been proding me to write up my thoughts on how to fix the IR  type system for LLVM 3.0.  Here are some (fairly stream of conscious) thoughts on the matter: > http://nondot.org/sabre/LLVMNotes/TypeSystemRewrite.txt > > Comments welcome! So struct types would unique by name. How

On 11-02-26 4:25 PM, Chris Lattner wrote: > Several people have been proding me to write up my thoughts on how to fix the IR type system for LLVM 3.0. Here are some (fairly stream of conscious) thoughts on the matter: > http://nondot.org/sabre/LLVMNotes/TypeSystemRewrite.txt Thanks! > Comments welcome! Having fewer types makes the job of the passes easier. Right now we maintain a

On Jul 12, 2011, at 5:04 AM, Vitaly Lugovskiy wrote: > Hi Chris, > > What's a new way of building recursive types (with C bindings), once > RefineType had been removed? And what's an exact reason for getting > rid of the opaque types - I could not find a relevant discussion in a > mailing list. Hi Vitaly, I didn't add this API, because I'm not very familiar

On 25 June 2011 13:00, Duncan Sands <baldrick at free.fr> wrote: >> 3. Clang/dragonegg need to adapt to the new API (help appreciated!) > > what needs to be done exactly? Background info: http://www.nondot.org/sabre/LLVMNotes/TypeSystemRewrite.txt As I understand it, PATypeHolder, OpaqueType and the Module's TypeSymbolTable are gone. Instead, StructTypes can optionally be

With the named/unnamed/anonymous distinctions there seems to be two things going on: 1. Giving an ID to a struct type. 2. Naming a type for readability. Would the new system force anonymous structs to be printed inline at every occurrence? The code might become hard to read with large anonymous types. Would it make sense to have both ID and Name? If a type has a name it could be printed using

Hi Chris, > 3. Clang/dragonegg need to adapt to the new API (help appreciated!) what needs to be done exactly? Ciao, Duncan.

Hello, I am running a i7 MacBook Pro 2011. If I write: @g = global double 0.000000e+00 define i32 @main() { entry: %0 = load double* @g %1 = fmul double 1.000000e+06, %0 store double %1, double* @g ret i32 0 } in test.ll and I run > llc test.ll > gcc test.s I get: test.s:12:no such instruction: `vmovsd _g(%rip), %xmm0' test.s:13:no such instruction: `vmulsd LCPI0_0(%rip),

On Thu, Aug 11, 2011 at 1:31 PM, Chris Lattner <clattner at apple.com> wrote: > > - "Named" structure type variables, e.g. %struct.foo > > - "Unnamed" structures type variables, e.g. %3 > > - "Literal" structure type expressions, e.g. { double, double } > > I like this! It is much better than the names I came up with. Any >

This looks like a good extension to the type system. One thing that I expected to work (when I first tried using opaque types) was for the optimization passes and verification to operate correctly when using opaque types, while the type could be made concrete later on - after optimization. This turned out to be impossible, and in combination with the lack of naming for opaque types, I

Hi, Is this correct behaviour? test.ll: declare {} @__ex__print_int(i64) define i32 @main() { entry: %0 = call i64 @f.1() %1 = call {} @__ex__print_int(i64 %0) ret i32 0 } define internal fastcc i64 @f.1() { entry: ret i64 7 } > opt -std-compile-opts test.ll -S ; ModuleID = 'test.ll' define i32 @main() noreturn nounwind { entry: tail call void @llvm.trap()

Hi, When calling a function, does the llvm code generator support passing structured types (arrays, structs, etc.) by _value_? I wrote some small examples, and it seemed to work, but I was wondering if anything can go wrong if the structured types are very large... Thanks, N

On Wed, Apr 6, 2011 at 10:48 PM, Nicolas Ojeda Bar <nojb at math.harvard.edu> wrote: > Hi, > > Is this correct behaviour? > > test.ll: > > declare {} @__ex__print_int(i64) > > define i32 @main() { > entry: >  %0 = call i64 @f.1() >  %1 = call {} @__ex__print_int(i64 %0) >  ret i32 0 > } > > define internal fastcc i64 @f.1() { > entry: >

On Mon, Aug 15, 2011 at 9:01 AM, Nicolas Ojeda Bar <nojb at math.harvard.edu> wrote: > Hi, > > When calling a function, does the llvm code generator support passing structured types (arrays, structs, etc.) by _value_? I wrote some small examples, and it seemed > to work, but I was wondering if anything can go wrong if the structured types are very large... It should work; the

Hello, This is a little off-topic. But I am writing a compiler to llvm ir for a language that admits recursive nested functions and am stuck as to how to translate them. Concretely, I'm trying to lift them all to the topmost level and pass all their free variables explicitly as arguments. To do this, I have to determine all their free variables in their bodies. In particular when I come

On Feb 27, 2011, at 9:48 AM, Rafael Ávila de Espíndola wrote: >> Comments welcome! > > Having fewer types makes the job of the passes easier. Right now we > maintain a small number of types as we go, which is expensive. In the > proposed change, would it still be legal to write a type merging pass? > For example, lets say we have > > %Foo = type { i32 } >

Hi Chris I have questions about new IR. > Named structs. > Unnamed structs (named structs with no names) > Anonymous structs (things like complex, which cannot be cyclic) > >Given this, the rules above would be that "only non-anonymous structs can have >cycles" for example. Arrays, pointers and other non-namable types can be >considered to be anonymous as well.