search for: eightbyte

...ing convention. No counting of numbers of registers in Clang to put "inreg" markers in the right places, or byval, or any of that sort of stuff it has to do today. For example, on x86-64 SysV ABI, a complex classification algorithm is run over the fields in an aggregate, to classify each eightbyte quantity into one of several classes (MEMORY, INTEGER, SSE, etc). That must run on the clang side, using source types, but it could send the direct result of the classification to llvm, rather than using it to mangle the prototype of the function in a secret undocumented handshake using the few see...

Apologies for the dumb questions but I'm rustier than I had hoped on this. I'm trying to write a mini ML implementation and am considering trying to optimize tuples into structs to avoid heap allocation when possible. Tuples are often used to return multiple values in ML so I am likely to wind up returning structs from functions. I also want to support as much of a C-like

On Thu, Dec 8, 2016 at 5:37 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > So IIUC basically the *only* reason for this IR change is that we don’t > want to pattern match in debug build? > I don't understand right now why we wouldn’t want to do this? > If we need to pattern match such a basic construct, it suggests to me that we have the wrong representation, and we

...> of registers in Clang to put "inreg" markers in the right places, or > > byval, or any of that sort of stuff it has to do today. > > > For example, on x86-64 SysV ABI, a complex classification algorithm > > is run over the fields in an aggregate, to classify each eightbyte > > quantity into one of several classes (MEMORY, INTEGER, SSE, etc). > > That must run on the clang side, using source types, but it could > > send the direct result of the classification to llvm, rather than > > using it to mangle the prototype of the function in a secret...