similar to: maximum value for alignstack function attribute?

I'm trying to use LLVM to create compiler-rt.o on Windows. I use this command from the compiler-rt project: [nix-shell:~/downloads/llvm-project/compiler-rt]$ clang -nostdlib -S -emit-llvm lib/builtins/udivti3.c -g -target x86_64-windows -DCRT_HAS_128BIT The resulting LLVM IR is: ================================================================= ; ModuleID = 'lib/builtins/udivti3.c'

The following comment: 00881 // As a hack, we allow "align 2" on functions as a synonym for "alignstack 00882 // 2". in "lib/AsmParser/LLParser.cpp" appears inaccurate, the "alignment" is later parsed as the alignment of the function itself, both when directly placed on the function: 02975 // If the alignment was parsed as an attribute, move

Hi, In sanitizer code we have two notions of stack unwinders: fast and slow. [1] In the context of sanitizers, stack unwinding is most often for printing error reports that include a stack trace. I am currently trying to fix an issue that is related to some platforms (Darwin) only supporting the fast unwinder, but calling code not being aware of that possibility. My mental model was that

Thank you for the explanation, Ben! I realized I didn’t give enough context for my question: As you noted, the slow/fast unwinder can only do its work if there is enough (runtime) information. Otherwise stack printing usually does exactly what you suggested: printing the one frame corresponding to the recent pc. When I asked if “platforms are required to at least support one kind of unwinder” I

Most probably you need to properly specify the calling convention the backend is using for calling the runtime functions. Or implement the stub for udivti3 that performs the necessary argument lifting. I guess there is no standard ABI document describing the intended calling convention here, so I'd just do what mingw64 does here and make everything here compatible. On Thu, Apr 26, 2018 at

On Thu, Apr 26, 2018 at 3:44 AM, Anton Korobeynikov <anton at korobeynikov.info > wrote: > Most probably you need to properly specify the calling convention the > backend is using for calling the runtime functions. Thanks for the tip. Can you be more specific? Are you suggesting there is some config parameter I can set before running TargetMachineEmitToFile? Do you know what

2018-01-24 0:23 GMT+08:00 Ben Craig <ben.craig at ni.com>: > The high level of what happens is that __builtin_eh_return forces a spill > of all the non-volatile registers. The unwinder then has a starting point > for populating and adjusting those non-volatile registers. > > > > This approach usually requires that the function calling > __builtin_eh_return be built

Cool this is better than I expected - I never thought about the YAML support. And the document reference is really very good. Thanks Francis, MartinO -----Original Message----- From: Francis Visoiu Mistrih [mailto:francisvm at yahoo.com] Sent: 05 February 2018 21:43 To: Martin J. O'Riordan <MartinO at theheart.ie> Cc: LLVM Developers <llvm-dev at lists.llvm.org>; Adam Nemet

Hi, I'm trying to fix an issue with clang's __force_align_arg_pointer__ attribute. The problem is described here: https://llvm.org/bugs/show_bug.cgi?id=26662 The problem is affecting Wine (https://www.winehq.org/) where we have a function that is an entry-point for the x86 Win32 abi. That function may then call functions in the host's (linux, OS/X, ...) abi. The issue is that the

I'm open to other suggestions. The problem is that these functions service an incoming abi stack alignment that differs from the host's abi alignment. An alternative would be to have the 'alignstack' IR attribute itself reduce the incoming stack alignment assumption. i.e. if it's specified then it's fair to assume that the incoming stack does not have the correct

David Terei wrote: > Hi all, > > I'm working on using LLVM as a back-end for the Haskell GHC compiler. As > part of that work I have modified LLVM to include a new custom calling > convention for performance reasons as outlined previously in a > conversation on this mailing list: > > http://nondot.org/sabre/LLVMNotes/GlobalRegisterVariables.txt > > This

Hi all, I'm working on using LLVM as a back-end for the Haskell GHC compiler. As part of that work I have modified LLVM to include a new custom calling convention for performance reasons as outlined previously in a conversation on this mailing list: http://nondot.org/sabre/LLVMNotes/GlobalRegisterVariables.txt This custom calling convention on x86-32 needs to handle just 4 parameters,

Are there any examples for the inline assembler or more complete docs? Questions: * What are the syntax and semantics of constraints? * If I load up specific registers in the inline assembly, will llvm make sure that those registers are unassigned or should I save the registers and restore them? i.e. does llvm try and understand what is going on in the inline assembly, or is it a black box to

On 22 Jan 2018, at 14:15, Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 1/19/2018 7:21 PM, 陳韋任 wrote: >> I see X86, Mips, XCore and Hexagon define their own EH_RETURN and lower to it, but others don't. May I know why it's so on Hexagon? > > Our exception handling runtime uses __builtin_eh_return. Does this mean that you know what it

On Nov 13, 2012, at 12:20 AM, Bill Wendling wrote: > IR Changes > ---------- > > The attributes will be specified within the IR. This allows us to generate code > that the user wants. This also has the advantage that it will no longer be > necessary to specify all of the command line options when compiling the bit code > (via 'llc' or 'clang'). E.g.,

target datalayout = "e-m:x-p:32:32-i64:64-f80:32-n8:16:32-a:0:32-S32" target triple = "i686-pc-windows-msvc" declare void @llvm.va_start(i8**) declare void @llvm.va_end(i8**) define i64 @foo(...) { %va = alloca i8*, i32 16 ; 4 words should be enough? call void @llvm.va_start(i8** %va) %x = va_arg i8** %va, i64 call void @llvm.va_end(i8** %va) ret i64 %x }

Hi! This is a proposal to expand the Attributes class to support many different options that will be accessible by all parts of the compiler. Please read and give any feedback you may have. Thanks! -bw Passing Options to Different Parts of the Compiler Problem ======= There is a growing need to pass information from the front-end to different parts of the compiler, especially

On Tue, Nov 20, 2012 at 11:03 AM, Meador Inge <meadori at codesourcery.com> wrote: > > On Nov 13, 2012, at 12:20 AM, Bill Wendling wrote: > >> IR Changes >> ---------- >> >> The attributes will be specified within the IR. This allows us to generate code >> that the user wants. This also has the advantage that it will no longer be >> necessary to

Hi, According to http://blogs.msdn.com/b/freik/archive/2006/03/07/x64-hotpatchability.aspx, 'hotpatchable' functions on x86 (and by extension, x86-64) are preceded by six bytes of padding and start with a two byte instruction. The problem is that, still being relatively unfamiliar with the x86 backend, I have no idea how to implement this for the 'hotpatch' attribute I just added.

llvm-generated code that runs fine on linux/i386 causes EXC_BAD_ACCESS with misaligned_stack_error_ on MacOS/i386. I read online that each function should have stack aligned by 16 on MacOS/i386 and such code should be used: Fn->addAttribute(~0U, llvm::Attribute::constructStackAlignmentFromInt(16)); But when I run clang on some C++ code I don't see alignstack instructions generated at