similar to: [LLVMdev] 64bit MRV problem: { float, float, float} -> { double, float }

Hey everybody, I am struggling to get rid of a problem which seems to be related to a multi-return value optimization: I generate bitcode for a c++-function with llvm-g++ which is then linked, transformed and optimized at runtime using LLVM. The function has quite a few parameters, including structs and struct-pointers with 3 float fields. The problem is, that I require the function to preserve

Hi Ralf, > llvm-gcc -c -emit-llvm -O3 produces this: > > %struct.float3 = type { float, float, float } > define void @test(double %a.0, float %a.1, %struct.float3* nocapture > %res) nounwind noinline { > entry: > %tmp8 = bitcast double %a.0 to i64 ; <i64> [#uses=1] > %tmp9 = zext i64 %tmp8 to i96 ; <i96> [#uses=1] >

Hey Duncan, hey everybody else, I just stumbled upon a problem in the latest llvm-gcc trunk which is related to my previous problem with the 64bit ABI and structs: Given the following code: struct float3 { float x, y, z; }; extern "C" void __attribute__((noinline)) test(float3 a, float3* res) { res->y = a.y; } int main(void) { float3 a; float3 res; test(a,

Uh, sorry, did not pay attention where I was replying ;) Hey Duncan, I do not understand why this behaviour is required. What is the problem in having a function receive a single struct-parameter with three floats compared to two scalar parameters? source-code (C++): struct Test3Float { float a, b, c; }; void test(Test3Float param, Test3Float* result) { ... } bitcode:

Hi Ralf, > I do not understand why this behaviour is required. What is the problem > in having a function receive a single struct-parameter with three floats > compared to two scalar parameters? > > source-code (C++): > struct Test3Float { float a, b, c; }; > void test(Test3Float param, Test3Float* result) { ... } if you compile this with GCC, you will see that it too

Ralf, Ok, thanks, I'll have a look. The paper I was referencing was http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.94.668 from '90 I believe. There is also an Intel paper the expands on this for the Itanium. On Fri, Jan 6, 2012 at 12:34 PM, Ralf Karrenberg < karrenberg at cdl.uni-saarland.de> wrote: > Hi, > > I am not sure if I know the paper you mentioned, but

Hi Arushi, > I was tracking the issue discussed earlier, and I was wondering if a bug for the > missed optimizations, was ever filed, and if it has been fixed since? If so in > which llvm version, and more specifically which optimization pass. > > http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-January/028877.html this doesn't really sound like an LLVM optimizer issue, it

Hi Micah, The numbers from the paper were measured with the ATI Stream SDK v2.1 (it's only mentioned in the references I think). The most recent measurements I have were done with the current v2.5. Best, Ralf Am 19.10.2011 23:43, schrieb Villmow, Micah: > Ralf, > What version of the SDK were you using for your analysis? I don't see that in the slides/pdf. > > Thanks, >

Hey Daniel, thanks for the response. > I believe all you need to do is call llvm::llvm_shutdown(). > I am not sure that this is what I need. When and how should I call llvm_shutdown()? After the FunctionPassManager is done, the calling ModulePass still performs quite a few actions on the transformed code and also calls the FunctionPassManager on different functions. However, I need

So, is there any chance that metadata for basic blocks is considered a useful feature? There is a patch ready and on the commits-list, it compiles, passes all tests, has a test case of its own, and (as far as I can tell) does not interfere with anything. Cheers, Ralf On 5/7/12 4:21 PM, Ralf Karrenberg wrote: > Hi Duncan, > > On 5/6/12 6:12 PM, Duncan Sands wrote: >> Hi Ralf,

If we were to implement the #unroll pragma, we would want to add metadata to loop headers. But, it's not a big deal since we can simply add this metadata to block terminators. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Dan Gohman Sent: Tuesday, May 08, 2012 00:58 To: Ralf Karrenberg Cc: llvmdev at cs.uiuc.edu List

Hi Duncan, On 5/6/12 6:12 PM, Duncan Sands wrote: > Hi Ralf, > >> Is there a clean way to attach metadata nodes to Arguments and/or >> BasicBlocks? > > not at the moment. Feel free to work on adding this functionality! I am looking into that now. I decided to temporarily go for the following syntax for BasicBlock metadata (subject to discussion): entry:

Indeed, Nadav. I also want to store information about loops as block-metadata of the loop header, but as you say this is easily doable by using block terminators. However, for the divergence analysis, we cannot use the terminators, because the properties of a block are determined by multiple criterions. If you do not want to introduce ugly dummy-calls to store that data (and write even more

Ralf, What version of the SDK were you using for your analysis? I don't see that in the slides/pdf. Thanks, Micah > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Ralf Karrenberg > Sent: Wednesday, October 19, 2011 2:13 PM > To: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] ANN: libclc (OpenCL C

Hi, I was tracking the issue discussed earlier, and I was wondering if a bug for the missed optimizations, was ever filed, and if it has been fixed since? If so in which llvm version, and more specifically which optimization pass. http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-January/028877.html Thanks, Regards, Arushi -------------- next part -------------- An HTML attachment was scrubbed...

Hi Ralf, I believe all you need to do is call llvm::llvm_shutdown(). - Daniel On Sun, Jul 26, 2009 at 11:51 AM, Ralf Karrenberg<Ralf.Karrenberg at gmx.de> wrote: > Hello everybody, > > is it somehow possible to get information about what passes were run in > what order  or timing analysis of passes *without* using opt? > I am implementing a ModulePass that at some point

Hi Ralf On Wednesday, June 1, 2011, Ralf Karrenberg <Chareos at gmx.de> wrote: > Hi, > > The last time the AVX backend was mentioned on this list seems to be > from November 2010, so I would like to ask about the current status. Is > anybody (e.g. at Cray?) still actively working on it? I don't think so! > I have tried both LLVM 2.9 final and the latest trunk, and it

On 21 September 2012 09:51, Ralf Karrenberg <Chareos at gmx.de> wrote: > Hi, > > Simon Moll (in CC) has written a decompiler for LLVM in his Bachelor's > Thesis here at Saarland University. The thesis is titled "Decompilation of > LLVM IR" and can be found here: > http://www.cdl.uni-saarland.de/publications/ > > The library he implemented is called

On May 7, 2012, at 7:21 AM, Ralf Karrenberg <Chareos at gmx.de> wrote: > Hi Duncan, > > On 5/6/12 6:12 PM, Duncan Sands wrote: >> Hi Ralf, >> >>> Is there a clean way to attach metadata nodes to Arguments and/or >>> BasicBlocks? >> >> not at the moment. Feel free to work on adding this functionality! > > I am looking into that

Thanks Syoyo and Bruno for your replies. As suggested, I filed a bug under http://llvm.org/bugs/show_bug.cgi?id=10073 . I am not familiar with .td files and the LLVM backend infrastructure yet, but I might give it a try and solve it myself if I find the time. Best, Ralf Am 02.06.2011 23:55, schrieb Bruno Cardoso Lopes: > Hi Ralf > > On Wednesday, June 1, 2011, Ralf