search for: relph

...th unstripped modules, that is passing test runs. When it still failed, I guessed the failure mode to be the same, but it isn't. Not sure WHAT to make of this... ________________________________________ From: Eli Friedman [eli.friedman at gmail.com] Sent: Friday, November 09, 2012 4:08 PM To: Relph, Richard Cc: LLVMdev at cs.uiuc.edu Subject: Re: [LLVMdev] Inlining bitcast functions... On Fri, Nov 9, 2012 at 3:58 PM, Relph, Richard <Richard.Relph at amd.com> wrote: > Eli, > Thanks. I don't think it's a bug in the linker, really… it's required to treat (stripped) o...

...l match the first barrier test and return AMDIL_barrier, not AMDIL_barrier_global. On Nov 29, 2012, at 7:19 PM, Chris Lattner <clattner at apple.com> wrote: > Out of curiosity, what is wrong about that? It looks ok to me. > > -Chris > > On Nov 29, 2012, at 6:52 PM, "Relph, Richard" <Richard.Relph at amd.com> wrote: > >> Should tablegen detect this as an error, or is it documented as a limitation somewhere that we've missed? >> >> In the tablegen-generated file AMDILGenIntrinsics.inc, we have a bunch of if statements comparin...

On Mon, Dec 3, 2012 at 2:08 PM, Relph, Richard <Richard.Relph at amd.com> wrote: > On Nov 21, 2012, at 4:28 PM, "Relph, Richard" <Richard.Relph at amd.com> wrote: > >> On Nov 21, 2012, at 12:09 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: >> >>> Note that I plan to remove...

On Nov 21, 2012, at 4:28 PM, "Relph, Richard" <Richard.Relph at amd.com> wrote: > On Nov 21, 2012, at 12:09 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: > >> Note that I plan to remove llvm/Bitcode/Archive once Object/Archive is >> capable of replacing it. The llvm tools that don't wr...

On Nov 21, 2012, at 12:09 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: > On Wed, Nov 21, 2012 at 8:55 AM, Relph, Richard <Richard.Relph at amd.com> wrote: >> AMD would like to add new functionality to ranlib (and later ar and nm) and >> to the bits of LLVM Core that read (and later write) archives. >> Herewith a terse summary of the change, which we want to improve support of >>...

...roublesome bitcast. I'll look in to instcombine, but if you've got any further words of advice on how to use it, they would be greatly appreciated. Thanks, Richard On Nov 9, 2012, at 3:33 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Fri, Nov 9, 2012 at 3:25 PM, Relph, Richard <Richard.Relph at amd.com> wrote: >> I've got a call instruction: >> call void bitcast (void (%4 addrspace(1)*, <2 x i32>, <4 x float>)* @_Z12write_imagefPU3AS110_image2d_tDv2_iDv4_f to void (%9 addrspace(1)*, <2 x i32>, <4 x float>)*)(%9 addr...

Hi Relph, I'm trying to print the value of 'a' while executing a.s = --depth; I have used break line number instead of break function so that the initial prologue part gets executed. The problem seems to be happening when parameters are pushed into stack and we call a function recursively. For...

On Fri, Nov 9, 2012 at 3:58 PM, Relph, Richard <Richard.Relph at amd.com> wrote: > Eli, > Thanks. I don't think it's a bug in the linker, really… it's required to treat (stripped) opaque types as different, since it really has no way to know if the caller and the callee really are referring to the same thing...

...apply your patches on top of that, letting people know where to get those sources so that they can build what they need. If this won't work then perhaps you can explain why you think you need to have multiple versions available in top of tree? Thanks! -eric On Fri, Dec 7, 2012 at 10:08 AM, Relph, Richard <Richard.Relph at amd.com<mailto:Richard.Relph at amd.com>> wrote: Is there a convention for how the LLVM community prefers to have conditional compilation in code intended to be checked in to llvm.org<http://llvm.org/>? Our goal is a single code base that can support mu...

...applied to trunk? On Fri, Nov 30, 2012 at 11:08 PM, Chris Lattner <clattner at apple.com> wrote: > Yes that definitely sounds like a bug, no intrinsically in mainline are a > prefix if another one, or we are getting lucky. > > -Chris > > On Nov 29, 2012, at 7:24 PM, "Relph, Richard" <Richard.Relph at amd.com> > wrote: > > > If the source being scanned has "llvm.AMDIL.barrier.global, it will > match the first barrier test and return AMDIL_barrier, not > AMDIL_barrier_global. > > > > > > On Nov 29, 2012, at 7:19 PM, C...

Yes that definitely sounds like a bug, no intrinsically in mainline are a prefix if another one, or we are getting lucky. -Chris On Nov 29, 2012, at 7:24 PM, "Relph, Richard" <Richard.Relph at amd.com> wrote: > If the source being scanned has "llvm.AMDIL.barrier.global, it will match the first barrier test and return AMDIL_barrier, not AMDIL_barrier_global. > > > On Nov 29, 2012, at 7:19 PM, Chris Lattner <clattner at apple.co...

Is there a convention for how the LLVM community prefers to have conditional compilation in code intended to be checked in to llvm.org? Our goal is a single code base that can support multiple LLVM revisions, including LLVM TOT. In the long run, of course, we'll simply be able to refer to the backend revision that corresponds to the revision of LLVM in use. If fixes between TOT and that older

...scope.) Does this sound reasonable? If so, who is active in the DWARF emitter and can help or advise on any relevant changes (since 2352.1, or planned) in this area? It does seem likely to me that this deficiency might have been addressed already, or at least have plans in place. Thanks, Richard Relph MTS | Stream Compute SW | AMD o. 408.749.6659 [cid:image001.jpg at 01CBEE7E.EC3D9560] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110330/ae15533d/attachment.html> -------------- next part ----------...

On Fri, Nov 9, 2012 at 3:25 PM, Relph, Richard <Richard.Relph at amd.com> wrote: > I've got a call instruction: > call void bitcast (void (%4 addrspace(1)*, <2 x i32>, <4 x float>)* @_Z12write_imagefPU3AS110_image2d_tDv2_iDv4_f to void (%9 addrspace(1)*, <2 x i32>, <4 x float>)*)(%9 addrspace(1...

...apply your patches on top of that, letting people know where to get those sources so that they can build what they need. If this won't work then perhaps you can explain why you think you need to have multiple versions available in top of tree? Thanks! -eric On Fri, Dec 7, 2012 at 10:08 AM, Relph, Richard <Richard.Relph at amd.com>wrote: > Is there a convention for how the LLVM community prefers to have > conditional compilation in code intended to be checked in to llvm.org? > > Our goal is a single code base that can support multiple LLVM revisions, > including LLVM T...

Out of curiosity, what is wrong about that? It looks ok to me. -Chris On Nov 29, 2012, at 6:52 PM, "Relph, Richard" <Richard.Relph at amd.com> wrote: > Should tablegen detect this as an error, or is it documented as a limitation somewhere that we've missed? > > In the tablegen-generated file AMDILGenIntrinsics.inc, we have a bunch of if statements comparing strings, many...

On Fri, Dec 07, 2012 at 08:58:21PM +0000, Relph, Richard wrote: > Eric, > Once both AMD and Apple have advanced their respective internal LLVM versions past the point where AMDIL went in to LLVM TOT, then we can rip out all the conditional code and just have the one LLVM TOT. This is about managing the transition to that utopia… ;-) &g...

I've got a call instruction: call void bitcast (void (%4 addrspace(1)*, <2 x i32>, <4 x float>)* @_Z12write_imagefPU3AS110_image2d_tDv2_iDv4_f to void (%9 addrspace(1)*, <2 x i32>, <4 x float>)*)(%9 addrspace(1)* %dstimg, <2 x i32> %28, <4 x float> %26) nounwind %4 and %9 are both (stripped) opaque structs. InlineFunction() does not inline this because

Should tablegen detect this as an error, or is it documented as a limitation somewhere that we've missed? In the tablegen-generated file AMDILGenIntrinsics.inc, we have a bunch of if statements comparing strings, many of which are dead, preventing correct recognition of some intrinsics in the their text form. I'm not quite sure what GET_FUNCTION_RECOGNIZER is used for, but if it's

Karthik, At what point within recurse() are you asking gdb to display the value of argument a? What I'm wondering about is if the debug information gdb is using to get at a might not be correct at the particular point you are checking a, particularly if that is before the prolog has completed execution. The way debug information for arguments pushed on the stack is represented in