similar to: [LLVMdev] Inreg firstclass structs

On Tue, Jul 8, 2008 at 2:28 AM, Matthijs Kooijman <matthijs at stdin.nl> wrote: > Hi all, > > I've been discussing parameter attributes and their impact on first-class > struct parameters. Duncan and I came to the conclusion that the only attribute > that could be applied to structs currently, is the inreg attribute. However, > since there is no support anywhere for

Hi Anders, Thanks for the patch. I'd like you to incorporate some feedback before I apply it, though. > Index: include/llvm/Argument.h > =================================================================== > --- include/llvm/Argument.h (revision 50213) > +++ include/llvm/Argument.h (working copy) > @@ -60,7 +60,16 @@ > + > + /// setByValAttr - Set true to give the

Hi.. Updated so you now set alignment through LLVMInstrSetAlignment. Anders Johnsen -------------- next part -------------- A non-text attachment was scrubbed... Name: ParamAttr.patch Type: text/x-diff Size: 7420 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080424/cb72b4bb/attachment.patch>

Hi Gordon, Thanks a lot for the feedback. I can see I've been way to concentrated on how llvm is build, then on this particular patch. I've done the changes you have suggested and it's now a lot nicer and cleaner! Please do say, if there is anything else. Anders Johnsen On Saturday 26 April 2008 22:02:45 Gordon Henriksen wrote: > Hi Anders, > > Thanks for the patch.

Functions with __attribute__((fastcall)) pop their arguments and take up to two arguments in ecx and edx. Currently we represent them by just setting the x86_fastcallcc calling convention. The problem is that the ABI has some strange conventions on when a register is used or not. For example: void __attribute__((fastcall)) foo1(int y); will take 'y' in ecx, but struct S1 { int x; };

I'm now writing a pass and I wanna ask a question about how to duplicate the function and add duplicated arguments in llvm, for example: func(int a, char *b) -> func(int a, char *b, int a1, char *b1) I'm now stuck at using "getOrInsertFunction" and how to handle "getArgumentList", please share your opinion, thanks a lot! James

Hi all, For anyone interested, I posted two new ideas for changes to the LLVM IR. The first is basically a cleanup, the second is a major new feature: Eliminating the 'Void' Type: http://nondot.org/sabre/LLVMNotes/EliminatingVoid.txt Aggregates as First Class Values: http://nondot.org/sabre/LLVMNotes/FirstClassAggregates.txt Thanks to Dan Gohman for convincing me that aggregates

On Fri, Dec 9, 2016 at 1:30 PM, Friedman, Eli via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 12/9/2016 8:45 AM, Reid Kleckner wrote: > > 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

Hi all, due to the recent changes regarding paramater/function/return type attributes, I think the documentation around that could use some improvement. In particular, I see the following problems: * The section "Functions" in the LangRef has a large textual description about how it should look, but no definition of syntax, or even a few examples of the syntax. This makes it very

On Wednesday 02 May 2012 09:12:16 Duncan Sands wrote: > > As I can understand, LLVM is trying to decompose datatypes into smaller > > components in some circumstances. > > Can you please explain more what you are referring to here. LLVM itself > shouldn't be changing function parameters or return types unless the > function has local (internal) linkage (since in that

Thanks Nick! ok. I ran through the verifier and this is the issue: verifying... Instruction does not dominate all uses! %tmp3 = add i32 %b, %a ; <i32> [#uses=2] store i32 %tmp3, i32* %0, align 4 Broken module found, compilation aborted! add is existing instruction in function. store is the instruction I have added to the function. How do I fix this now :(? Thanks, Bhavani --- On Mon,

Personally, I'd love to see a setup where instead of LLVM implementing each calling convention and ABI hack, we provide a means of actually describing this. Specifically, I'd love to see a design for how to specify in the IR which register(s) (if any register(s)) a particular value should be placed into. Don't get me wrong, I don't have any good ideas about how to do this, I'm

This patch will improve the flow at disk_write_sectors and disk_read_sectors significantly, but it *will* introduce bugs if either of the above functions gets called before disk_get_params. --- com32/include/syslinux/disk.h | 21 +++++ com32/lib/syslinux/disk.c | 170 +++++++++++++++++++++-------------------- 2 files changed, 108 insertions(+), 83 deletions(-) diff --git

On Fri, Dec 9, 2016 at 4:04 PM, James Y Knight <jyknight at google.com> wrote: > IMO, the LLVM function definitions should be a straightforward > transformation from the C function signatures, and clang should stop > mangling the function signatures with its own intimate knowledge of the > calling convention rules. > > Instead, clang could emit (still ABI-specific!)

This patch will improve the flow at disk_write_sectors and disk_read_sectors. It does that by creating a table of values respective to the operation. Besides, read and write operations are pretty similar to each other, so I redesigned the routines to avoid duplication. Signed-off-by: Raphael S.Carvalho <raphael.scarv at gmail.com> --- com32/include/syslinux/disk.h | 18 ++++

Hi Tim, On 02/05/12 10:51, Tim Northover wrote: > On Wednesday 02 May 2012 09:12:16 Duncan Sands wrote: >>> As I can understand, LLVM is trying to decompose datatypes into smaller >>> components in some circumstances. >> >> Can you please explain more what you are referring to here. LLVM itself >> shouldn't be changing function parameters or return

Hi Peter Anvin I tried to use open file and read file SYSLINUX API. But it always make my PC104 freeze. My snip code : ================================================ int __start(void) { int ax,cx,dx,es,si,di,t; com32sys_t inreg,outreg; memset(&inreg, 0, sizeof inreg); memset(&outreg, 0, sizeof outreg); strcopy(__com32.cs_bounce, "test.txt"); inreg.eax.w[0] = 0x0006; //

Here is a partial patch that I'm using to illustrate a few questions that I have. Looking at the gpllib write_sectors (com32/gpllib/disk/write.c) it looks like the allocated size is wrong; size is in sectors so we should adjust the alloc/memcpy by size*SECTOR. Also, comparing core/diskio.c it looks like the registers aren't even setup right. In the patch below I put an #if 0 around the

Hi, after working with llvm for a while, I'm still a little confused with the meaning of the 'byval' attribute. From the langref: "This indicates that the pointer parameter should really be passed by value to the function. The attribute implies that a hidden copy of the pointee is made between the caller and the callee, so the callee is unable to modify the value in the callee.

Adding Support For Vectorcall Calling Convention ===================================================== Vectorcall Calling Convention for x64 ---------------------------------------------------- The __vectorcall calling convention specifies that arguments to functions are to be passed in registers, when possible. __vectorcall uses more registers for arguments than __fastcall or the default x64