search for: alignstack

I have this test case in my frontend, which is triggering an assert in llvm master branch: fn fnWithAlignedStack() -> i32 { @setAlignStack(1024); return 1234; } It sets alignstack=1024 in the function attributes (see http://llvm.org/docs/LangRef.html#function-attributes). It's tripping an assert: llvm/lib/IR/Attributes.cpp:134: static llvm::Attribute llvm::Attribute::getWithStackAlignment(llvm::LLVMContext&, uint64_t): A...

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 to the alignment field....

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 alignment, so we should assume it has a smaller alignment - which we would probably just pick as 4. Would that be any...

...call functions in the host's (linux, OS/X, ...) abi. The issue is that the Win32 abi guarantees stack alignment of four bytes while the host abi is typically sixteen. This is supposed to be solved by clang's __force_align_arg_pointer__ attribute. What this does is to set the IR attribute alignstack = 16. While this does correctly realign the stack it does not change the assumption about the alignment of the incoming stack - which is still assumed to have an alignment of sixteen. We need a way to signal to the stack layout generator that the incoming alignment can only be assumed to be four....

...ned 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 llvm analysis? * What is the syntax of the inline assembly? i.e. intel, att, ...? The test code is complete mystery to me: ; From test/Assembler/alignstack.II define void @test1() nounwind { ; CHECK: test1 ; CHECK: sideeffect ; CHECK-NOT: alignstack tail call void asm sideeffect "mov", "~{dirflag},~{fpsr},~{flags}"() nounwind ret void ; CHECK: ret } * Presumably "mov" is the inline assembly string, but that isn't...

...or another, if you want to make a dylib call on Mac OS X. > > I'm hoping someone is able to confirm that my changes would have > introduced this bug and how to go about fixing it. Something I'm doing right now may be of interest to you. Just today I added support for a new 'alignstack' function attribute. With it, you can force the stack to be 16-byte aligned (or n-byte aligned, if you so desire) in your functions. This way, you can make calls to dylibs on Mac OS X without triggering the misaligned stack error. Of course, it's a no-op right now (I still have to do the b...

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,

Charles Davis wrote: > Just today I added support for a new 'alignstack' function attribute. > With it, you can force the stack to be 16-byte aligned (or n-byte > aligned, if you so desire) in your functions. This way, you can make > calls to dylibs on Mac OS X without triggering the misaligned stack error. I finally got around to properly playing around...

...he attribute group's ID: > > attribute_group_ref := attrgroup(<attrgroup_id>) > > This is an example of an attribute group for a function that should always be > inlined, has stack alignment of 4, and doesn't unwind: > > attrgroup #1 = { alwaysinline, nounwind, alignstack=4 } > > void @foo() attrgroup(#1) { ret void } > > An object may refer to more than one attribute group. In that situation, the > attributes are merged. > > Attribute groups are important for keeping `.ll' files readable, because a lot > of functions will use the same...

...vm.va_end(i8** %va) ret i64 %x } ;; should return 123 define i32 @main() { %val0 = call i64(...) @foo(i64 123) %res = trunc i64 %val0 to i32 ret i32 %res } Running this returns mostly 0, but sometimes 123. $ while sleep 1; do lli bug.ll; echo $?; done 123 0 0 0 123 0 0 Adding { alignstack=8 } to main makes it always return 123. Is this a bug or just a missing piece of documentation? Cheers, -- nikodemus -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171105/a4fd8c46/attachment.html>

...>> >> attribute_group_ref := attrgroup(<attrgroup_id>) >> >> This is an example of an attribute group for a function that should always be >> inlined, has stack alignment of 4, and doesn't unwind: >> >> attrgroup #1 = { alwaysinline, nounwind, alignstack=4 } >> >> void @foo() attrgroup(#1) { ret void } >> >> An object may refer to more than one attribute group. In that situation, the >> attributes are merged. >> >> Attribute groups are important for keeping `.ll' files readable, because a lot >&gt...

...ID: >> >> attribute_group_ref := attrgroup(<attrgroup_id>) >> >> This is an example of an attribute group for a function that should always be >> inlined, has stack alignment of 4, and doesn't unwind: >> >> attrgroup #1 = { alwaysinline, nounwind, alignstack=4 } >> >> void @foo() attrgroup(#1) { ret void } >> >> An object may refer to more than one attribute group. In that situation, the >> attributes are merged. >> >> Attribute groups are important for keeping `.ll' files readable, because a lot >> o...

...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. I do remember the emitPrologue() method from when I was working on the alignstack() attribute, but I still don't know how to implement the first part (the six bytes of padding). Does anyone have any pointers? Chip

...D_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 all. What is the right way for fix this misaligned_stack_error? Yuri

...by copy: vec3 vec3::Cross(const vec3& iV) const; Here is the LLVM IR that I am generating for win32 ABI, which says that the first parameter should be a pointer to the return value: %vec3 = type <{ float, float, float }> define void @CPP_Return_Struct(%vec3* %v1, %vec3* %v2) inlinehint alignstack(16) { ENTRY: %"@0" = alloca %vec3, align 4 call x86_thiscallcc void @vec3_Cross(%vec3* sret %"@0", %vec3* %v1, %vec3* %v2) ret void } declare x86_thiscallcc void @vec3_Cross(%vec3* sret, %vec3*, %vec3*) align 2 It seems that the code generated by the JIT takes the first...

...ute group, an object references the attribute group's ID: attribute_group_ref := attrgroup(<attrgroup_id>) This is an example of an attribute group for a function that should always be inlined, has stack alignment of 4, and doesn't unwind: attrgroup #1 = { alwaysinline, nounwind, alignstack=4 } void @foo() attrgroup(#1) { ret void } An object may refer to more than one attribute group. In that situation, the attributes are merged. Attribute groups are important for keeping `.ll' files readable, because a lot of functions will use the same attributes. In the degenerative case o...

...> … >> >> function_def := <attribute_list> <result_type> @<id> ([argument_list]) <attribute_list> >> > So something like this (no references inside of the 'attributes' statement allowed, cf. above)? > > attributes #1 = { noinline, alignstack=4 } > attributes #2 = { "no-sse" } > > define void @foo() #1 #2 { ret void } > > This seems reasonable to me. Me too. This seem pretty close to what was implemented in the patches posted on llvm-commits. I review those in a bit. -- Meador Inge CodeSourcery / Mentor...

...amp; iV) const; > > Here is the LLVM IR that I am generating for win32 ABI, which says that the > first parameter should be a pointer to the return value: > > %vec3 = type <{ float, float, float }> > > define void @CPP_Return_Struct(%vec3* %v1, %vec3* %v2) inlinehint > alignstack(16) { > ENTRY: >  %"@0" = alloca %vec3, align 4 >  call x86_thiscallcc void @vec3_Cross(%vec3* sret %"@0", %vec3* %v1, %vec3* > %v2) >  ret void > } > > declare x86_thiscallcc void @vec3_Cross(%vec3* sret, %vec3*, %vec3*) align 2 > > It seems that t...

...I than LLVM will use when you do i128 division. For example, here is my test case (in zig code): ================================================================= pub extern "kernel32" stdcallcc fn ExitProcess(exit_code: c_uint) noreturn; export fn WinMainCRTStartup() noreturn { @setAlignStack(16); @setRuntimeSafety(false); var a: u128 = 152313999999999991610955792383; var b: u128 = 10000000000000000000; var c = a / b; // this generates a call to __udivti3 if (c != b) { @breakpoint(); } ExitProcess(0); } export fn __udivti3(a: u128, b: u128) u128 {...

...; do i128 division. For example, here is my test case (in zig code): > ================================================================= > > pub extern "kernel32" stdcallcc fn ExitProcess(exit_code: c_uint) noreturn; > > export fn WinMainCRTStartup() noreturn { > @setAlignStack(16); > @setRuntimeSafety(false); > > var a: u128 = 152313999999999991610955792383; > var b: u128 = 10000000000000000000; > var c = a / b; // this generates a call to __udivti3 > > if (c != b) { > @breakpoint(); > } > ExitProcess(0);...