On Fri, Feb 12, 2010 at 7:22 AM, David Greene <dag at cray.com> wrote:> On Thursday 11 February 2010 20:01:44 Dan Gohman wrote: > >> I was talking about MachineMemOperands in the above, not metadata. >> >> But that does suggest a consideration: if you're using metadata at >> the LLVM IR level, it may make sense to use metadata at the codegen >> level too, to avoid this confusion. > > There doesn't appear to be any way to do this right now. Is it planned?Today, we use metadata to represent debug info at LLVM IR level as well at the codegen level. - Devang
On Monday 15 February 2010 11:56:05 Devang Patel wrote:> On Fri, Feb 12, 2010 at 7:22 AM, David Greene <dag at cray.com> wrote: > > On Thursday 11 February 2010 20:01:44 Dan Gohman wrote: > >> I was talking about MachineMemOperands in the above, not metadata. > >> > >> But that does suggest a consideration: if you're using metadata at > >> the LLVM IR level, it may make sense to use metadata at the codegen > >> level too, to avoid this confusion. > > > > There doesn't appear to be any way to do this right now. Is it planned? > > Today, we use metadata to represent debug info at LLVM IR level as > well at the codegen level.So what's the trick? I don't see anything about metadata in the SelectionDAG stuff. -Dave
>> >> But that does suggest a consideration: if you're using metadata at >> >> the LLVM IR level, it may make sense to use metadata at the codegen >> >> level too, to avoid this confusion. >> > >> > There doesn't appear to be any way to do this right now. Is it planned? >> >> Today, we use metadata to represent debug info at LLVM IR level as >> well at the codegen level. > > So what's the trick? I don't see anything about metadata in the SelectionDAG > stuff.1) See DebugLoc.h. Now debug location tracker keeps track of metadata nodes. In 2.6 release debug location tracker tracked 4 element tuple. 2) See how X86 lowers @llvm.dbg.declare intrinsic into DBG_VALUE MI. - Devang