similar to: [LLVMdev] First class aggregates of small size: split when used in function call

> Do all tests need it? Align is just for non-default alignment (> align(1)) so it may be OK for the tests to omit it & it's probably not right to /require/ an align attribute on a byval parameter. I've had to fix some of the tests which checked that the right alignment was applied, by looking at the generated asm, but had no "align A" attributes and relied on the

Hi, In the past months, several options have been presented for making byval (and similar attributes, such as inalloca or sret) work with opaque pointers. The main two I've seen were byval(T) and byval(N) where N is the size of T. They both have their upsides and downsides, for example: byval(T) would be a type-parametric attribute, which, AFAIK, does not already exist and may complicate

On Jun 2, 2008, at 11:11 PM, Tanya Lattner wrote: > Darwin/ppc: > SingleSource/Benchmarks/CoyoteBench/fftbench [ CBE ] > From what I can see comparing 2.3 with TOT, the "cexp" function is declared like this in 2.3: declare i128 @cexp({double, double}* byval) nounwind It used to be this: declare void @cexp({double, double}* noalias sret, {double, double}* byval)

It was happening in a few files using COFF.h in LLDB for the windows branch (Windows.h is required for some typedef over Mutex, thread, socket, etc...). As said before, I am currently checking if it could be avoided (probably some refactoring will be needed). However I was wondering if it might not be easier to just avoid this clash at all by avoiding it in LLVM. Alternatively I could #undef

Right now, we have: In COFF.h: class COFF { enum MachineTypes { IMAGE_FILE_MACHINE_UNKNOWN = 0x0, ... }; }; In windows.h: #define IMAGE_FILE_MACHINE_UNKNOWN 0 * If you first include COFF.h and then windows.h, COFF::IMAGE_FILE_MACHINE_UNKNOWN will be preprocessed into COFF:0. * If you first include Windows.h and then COFF.h, COFF.h won't work because it's enum will

Hi LLVM folks, To properly implement pass-by-value in the Microsoft C++ ABI, we need to be able to take the address of an outgoing call argument slot. This is http://llvm.org/PR5064 . Problem ------- On Windows, C structs are pushed right onto the stack in line with the other arguments. In LLVM, we use byval to model this, and it works for C structs. However, C++ records are also passed this

On Aug 28, 2013, at 7:05 PM, Virgile Bello <virgile.bello at gmail.com> wrote: > Right now, we have: > In COFF.h: > class COFF { enum MachineTypes { IMAGE_FILE_MACHINE_UNKNOWN = 0x0, ... }; }; > In windows.h: > #define IMAGE_FILE_MACHINE_UNKNOWN 0 > > * If you first include COFF.h and then windows.h, > COFF::IMAGE_FILE_MACHINE_UNKNOWN > will be

In the Windows SDK headers, is the IMAGE_* defines in a separate file (e.g. winint.h)? Does the file have a guard against multiple inclusion? If so (and the guard was named _WINNT_H_), perhaps you can do something like: #define _WINNT_H_ #include <windows.h> So you would get everything except those file format defines. Of course, this would fail if other parts of the windows header rely

On 08/03/2015 18:07, Daniel Berlin wrote: > > > On Sun, Mar 8, 2015 at 9:55 AM, Nicholas Chapman > <admin at indigorenderer.com <mailto:admin at indigorenderer.com>> wrote: > > Hi all, > I have identified what seems to be a limitation of LLVM with > regard to marking 'sret functions' as pure/readonly. > > For some context - I have

On Wednesday 04 Apr 2012 12:41:49 Patrik Hägglund H wrote: > Hi Tim, > > > So I've come to the conclusion that the real flaw is LLVM > > not exposing enough information to the target-dependent > > backend code for it to do the right thing. > > We also had this problem. You might find this patch useful as a starting > point:

The odds of #define _WINNT_H working are incredibly slim :) You can't include the separate headers (winbase.h etc), you have to just include windows.h Windows defines IMAGE_* whether we like it or not, we can't stop it doing it, so the only reasonable solution is to change LLVM to have it's own set of constant names. Nick Kledzik wrote: > In the Windows SDK headers, is the

Yes of course I understand it was done on purpose. It's just that it makes it impossible to include COFF.h and Windows.h side by side (which probably wasn't necessary until now). On Wed, Aug 28, 2013 at 9:52 AM, Reid Kleckner <rnk at google.com> wrote: > IMO the fact that it uses the standard names from the COFF documentation > is a feature, not a bug. > > The elf and

Hello, I noticed that if include\llvm\Support is included alongside Windows.h, there will be many define conflict leading to compilation errors, such as: COFF.h (enum): enum MachineTypes { IMAGE_FILE_MACHINE_UNKNOWN = 0x0, ... }; and winnt.h (same but define): #define IMAGE_FILE_MACHINE_UNKNOWN 0 Of course I could try to avoid to include both (but it's rather difficult and would require

Hi all, I'm new on the list, so I want to say hello for everybody! I'm from Hungary and writing a LLVM backend for Tile64 processor as my master's thesis. It's a big time pressure on me, so the thesis will probably describe a backend only providing an assembly printer, but the development is likely to be continued beyond the thesis. For now, I've run into a very annoying

Moving this to llvm-dev where I should've sent it in the first place (& +Chandler, because we discussed this offline a bit) On Thu, Feb 19, 2015 at 11:32 AM, Reid Kleckner <rnk at google.com> wrote: > On Thu, Feb 19, 2015 at 10:57 AM, David Blaikie <dblaikie at gmail.com> > wrote: > >> >> >> On Thu, Feb 19, 2015 at 8:31 AM, Rafael Espíndola <

On Mon, Jul 29, 2013 at 10:45 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Reid, > > > On 29/07/13 16:36, Reid Kleckner wrote: > >> On Mon, Jul 29, 2013 at 9:40 AM, Duncan Sands <baldrick at free.fr >> <mailto:baldrick at free.fr>> wrote: >> >> On 29/07/13 15:30, Anton Korobeynikov wrote: >> >> object

What is the correct procedure for translating a function signature from a high-order language to LLVM? It looks like I replace each struct/array parameter with a 'byval' pointer parameter, and I replace a result struct/array with an 'sret' pointer parameter. The reason I ask is that each calling convention has subtle variations for each architecture and platform. For

IMO the fact that it uses the standard names from the COFF documentation is a feature, not a bug. The elf and macho headers in the same directory use the standard enumeration names, correct? On Tue, Aug 27, 2013 at 5:41 PM, Virgile Bello <virgile.bello at gmail.com>wrote: > Hello, > > I noticed that if include\llvm\Support is included alongside Windows.h, > there will be many

On Aug 27, 2013, at 5:56 PM, Virgile Bello <virgile.bello at gmail.com> wrote: > Yes of course I understand it was done on purpose. > It's just that it makes it impossible to include COFF.h and Windows.h side by side (which probably wasn't necessary until now). I too am in the camp that it is a feature to use the standard names. For instance doing a search it google or

Hi, (Forward from cfe-commits, where some backend stuff has come up). This is an issue I've been thinking about quite a bit recently, and I agree that the biggest problem is the one below: > * The big thing still missing here is that there is no logic to check how many VFP registers have already been used for other arguments. When deciding whether to pass an argument as a homogeneous