search for: getstackalign

...rget.h the methods seem a bit disordered, therefore I would propose to sort them new: -getTargetTriple() -cpu features (e.g. hasSSE1()) -os types (e.g. isTargetDarwin()) -object types (e.g. isTargetELF()) -callconv related functions (e.g. isTargetWin64(), consider renaming to isCallConvWin64(), getStackAlignment()) -pic functions perhaps my problem of generating elf objects on windows can be easily solved by creating a new os type, just like mingw and cycwin, and patching X86Subtarget.h accordingly (of course only in my private copy, i doubt it will be of general use) -Jochen

...ode assumes 256bit alignment, your default stack > alignment is 128bit and LLVM doesn't adjust it automatically? > > Joerg > Hey Joerg, The faulty code can be found in function X86InstrInfo::storeRegToStackSlot(...) from /lib/Target/X86/X86InstrInfo.cpp. > bool isAligned = (RI.getStackAlignment() >= 16) || RI.canRealignStack(MF); When creating the spill's machine instruction, the spill slot is assumed to be aligned if the alignment is >= 16 bytes, which is not the case for AVX. AVX spills require 32 byte alignment to make use of aligned moves. The stack is not adjusted auto...

Even if you explicitly specify –stack-alignment=16 the aligned movs are still generated. It is not an issue related to ABI. See my original mail: ./llc -mattr=+avx -stack-alignment=16 < basic.ll | grep movaps | grep ymm | grep rbp vmovaps -176(%rbp), %ymm14 vmovaps -144(%rbp), %ymm11 vmovaps -240(%rbp), %ymm13 - Elena From: Cameron McInally

...nfo.h (working copy) > @@ -84,7 +84,7 @@ > > /// getX86RegNum - Returns the native X86 register number for the > given LLVM > /// register identifier. > - unsigned getX86RegNum(unsigned RegNo) const; > + static unsigned getX86RegNum(unsigned RegNo); > > unsigned getStackAlignment() const { return StackAlign; } > > Index: lib/Target/X86/X86InstrInfo.cpp > =================================================================== > --- lib/Target/X86/X86InstrInfo.cpp (revision 49716) > +++ lib/Target/X86/X86InstrInfo.cpp (working copy) > @@ -24,7 +24,9 @@ >...

OK, here's a new patch that adds the infrastructure and the implementation for X86, ARM and PPC of GetInstSize and GetFunctionSize. Both functions are virtual functions defined in TargetInstrInfo.h. For X86, I moved some commodity functions from X86CodeEmitter to X86InstrInfo. What do you think? Nicolas Evan Cheng wrote: > > I think both of these belong to TargetInstrInfo. And

...del CM, > + CodeGenOpt::Level OptLevel > +) > +: > + LLVMTargetMachine(T, TT, CPU, FS, Options, RM, CM, OptLevel), > + Subtarget(TT, CPU, FS), > + DataLayout(Subtarget.getDataLayout()), > + FrameLowering(TargetFrameLowering::StackGrowsUp, > + Subtarget.device()->getStackAlignment(), 0), > + IntrinsicInfo(this), > + InstrItins(&Subtarget.getInstrItineraryData()), > + mDump(false) > + > +{ > + // TLInfo uses InstrInfo so it must be initialized after. > + if (Subtarget.device()->getGeneration() <= AMDILDeviceInfo::HD6XXX) { > + Ins...

...vm__unsafe_stack_ptr must be thread-local"); + } + + // TODO: check other attributes? + } + } + + return Changed; +} + +bool SafeStack::runOnFunction(Function &F) { + ++NumFunctions; + + unsigned StackAlignment = + TM->getSubtargetImpl(F)->getFrameLowering()->getStackAlignment(); + + SmallVector<AllocaInst*, 16> StaticAlloca; + SmallVector<AllocaInst*, 4> DynamicAlloca; + SmallVector<ReturnInst*, 4> Returns; + + // Collect all points where stack gets unwinded and needs to be restored + // This is only necessary because the runtime (setjmp and u...