similar to: [LLVMdev] Pass and return of large objects

On Mon, Mar 1, 2010 at 3:20 PM, Anton Korobeynikov <anton at korobeynikov.info> wrote: > Yes, it should. Hmm, Duncan Sands says otherwise? > But on many (almost all platforms) this will surely > overflow the stack. Well, the stack size can usually be tweaked at runtime. But suppose we have the default stack size, and replace the 10 MB object with 100 kB, the question stands.

> Suppose you have something like 'struct foo { char data[10000000]; }', > and you want to pass such objects as function parameters, and return > them as function results, by value, does this currently work correctly > on all supported target platforms? Yes, it should. But on many (almost all platforms) this will surely overflow the stack. Also, these objects are not supported

Oh... :( Are there any plans to change this? It's needed for a correct implementation of C, after all. On Mon, Mar 1, 2010 at 3:14 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi Russell, > >> Suppose you have something like 'struct foo { char data[10000000]; }', >> and you want to pass such objects as function parameters, and return >> them as

Hi Russell, > Suppose you have something like 'struct foo { char data[10000000]; }', > and you want to pass such objects as function parameters, and return > them as function results, by value, does this currently work correctly > on all supported target platforms? as far as I know this only works on x86, and only with LLVM from svn. Ciao, Duncan.

On Mon, Mar 1, 2010 at 6:00 PM, Dale Johannesen <dalej at apple.com> wrote: > No, C only requires support for objects up to 65535 bytes in size.  C99 5.2.4.1. 65535 bytes would be reasonably sufficient; what's the largest supported by the LLVM code generator?

Well yes, LLVM is Turing complete :-) but I take your point, one could in a pinch hack the same functionality in the front-end. Would that likely be easier or harder than doing it properly in the code generator? Other things equal, of course the latter would be preferable. How do LLVM-GCC and Clang handle it? On Mon, Mar 1, 2010 at 3:36 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi

On Mar 1, 2010, at 7:18 AMPST, Russell Wallace wrote: > Oh... :( > > Are there any plans to change this? It's needed for a correct > implementation of C, after all. No, C only requires support for objects up to 65535 bytes in size. C99 5.2.4.1. > On Mon, Mar 1, 2010 at 3:14 PM, Duncan Sands <baldrick at free.fr> wrote: >> Hi Russell, >> >>>

On Mon, Mar 1, 2010 at 7:39 PM, Reid Kleckner <rnk at mit.edu> wrote: > IIRC they lower it themselves, doing whatever the ABI says they > should, which is usually adding a hidden sret parameter to the > function once you get beyond small structs. Okay, so we seem to be saying sret or suchlike is how you pass and return large objects by value in LLVM. What exactly counts as large?

Hi Reid, >> I hadn't realized that, I would've expected complex numbers to be >> doable as just a pair of scalar values. What's the fly in the ointment >> with C99 complex numbers? the x86-64 ABI requires complex numbers to be passed *differently* to a pair of scalar values. So if the LLVM code generators were to do the lowering, then there would need to be a way

Hi all, I've started work on a new programming language for which I am considering using LLVM as the backend, and trying to experiment with it using the Kaleidoscope demo compiler. Taking the full source listing from http://llvm.org/docs/tutorial/LangImpl3.html#code and trying to compile it with the provided instructions gives me the following errors: a at a-desktop:~$ g++ -g -O3 toy.cpp

Hi Russel, > Are there any plans to change this? It's needed for a correct > implementation of C, after all. I guess it will happen when someone needs it enough. My understanding is that it wouldn't be hard to implement for most processors. By the way, you are wrong to say that it is needed for a correct implementation in C. Here's an analogy: consider the x86 instruction

On Mon, Mar 1, 2010 at 10:58 AM, Russell Wallace <russell.wallace at gmail.com> wrote: > How do LLVM-GCC and Clang handle it? IIRC they lower it themselves, doing whatever the ABI says they should, which is usually adding a hidden sret parameter to the function once you get beyond small structs. It'd be nice to move some of that logic back into LLVM, but it's tricky because C99

On Mon, Mar 1, 2010 at 8:34 PM, Russell Wallace <russell.wallace at gmail.com> wrote: >> It'd be nice to move some >> of that logic back into LLVM, but it's tricky because C99 says things >> about complex numbers which requires special frontend type knowledge >> that LLVM doesn't have. > > I hadn't realized that, I would've expected complex

Hi Russell, > Hmm. I've already decided to implement complex numbers basically the > classic C++ way, as a template. On the bright side, hopefully that > means the LLVM code generators will end up putting them in pairs of > registers. On the downside, I suppose that means I'll be honoring the > x86-64 ABI for complex numbers in the breach rather than the > observance. Is

Oh! Hmm. I've already decided to implement complex numbers basically the classic C++ way, as a template. On the bright side, hopefully that means the LLVM code generators will end up putting them in pairs of registers. On the downside, I suppose that means I'll be honoring the x86-64 ABI for complex numbers in the breach rather than the observance. Is that going to have any horribly bad

On Tue, Mar 2, 2010 at 2:34 AM, Dan Gohman <gohman at apple.com> wrote: > If you're wondering what this limit is, you're probably heading down > the wrong path, unless you're ultimate interest here is to work on > optimizer techniques for transforming this kind of code into > something usable. No, I'm just trying for correctness -- most of the time, only small

On Mar 1, 2010, at 2:49 PM, Russell Wallace wrote: > On Mon, Mar 1, 2010 at 6:00 PM, Dale Johannesen <dalej at apple.com> wrote: >> No, C only requires support for objects up to 65535 bytes in size. C99 5.2.4.1. > > 65535 bytes would be reasonably sufficient; what's the largest > supported by the LLVM code generator? If you're wondering what this limit is,

Thanks for your reply. I have a normal (../configure --enable-profiling --disable-optimized --enable-assertions) llvm debug+profile+assert build. I am generating llvm-bitcode using following commands. llvm-gcc -DLINUX_i386 -DSPEC_CPU2000 -O3 -emit-llvm 186.crafty/src/valid.c -c -o 186.crafty/src/valid.bc --- llvm-link 186.crafty/src/*.bc -o 186.crafty/186.crafty.rel.bc and finally: llc

Yep check out PR1324. Doing something like this would be a great improvement. -Chris On Jan 21, 2012, at 9:42 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Anton, in a solution without CAZ, isNullValue can just return true when it > sees the special "this ConstantArray is all zero" flag. So all the places that > now look for CAZ can just use isNullValue instead

Anton, what do you think of David's patch with this test case? OK to commit that? On Wed, Feb 20, 2013 at 12:43 PM, Anton Korobeynikov < anton at korobeynikov.info> wrote: > The patch looks incorrect. The code just needs to handle \1 properly > and clang extended to add explicit \1 to the names which does not > require mangling. > > I do not think that moving whole