similar to: [LLVMdev] broken alignment in stack(caused by bug in SelectionDAGBuilder) causes invalid schedules with r125471 and newer

Hi all, I'm learning the PTX backend and confused by the following problem. In the constructor of PTXFrameLowering, StackAlignment and LocalAreaOffset are assigned 2 and -2, respectively. Since PTX has neither stack frame nor stack pointer, why StackAlignment and LocalAreaOffset are needed and where does 2 and -2 come from? Any explanation is appreciated. Thank you in advance! Yours

On Mon, Apr 16, 2012 at 3:48 AM, Lei Mou <lei.mou.uu at gmail.com> wrote: > Hi all, > > I'm learning the PTX backend and confused by the following problem. In the > constructor of PTXFrameLowering, StackAlignment and LocalAreaOffset are > assigned 2 and -2, respectively. Since PTX has neither stack frame nor > stack pointer, why StackAlignment and LocalAreaOffset are

> When enabling and compiling this with mingw on Win32, my debugger > complains about heap overruns when calling speex_encoder_destroy(). This > could be a mingw issue though, as I also found a stackalignment bug which > prevents me from _USING_SSE (apparantly -mpreferred-stack-size is just > "prefered" and therefore ignored... *Sigh*). Just so I understand, the

On Tue, Oct 23, 2012 at 12:56 PM, Eric Christopher <echristo at gmail.com>wrote: > > Thanks for replying so quickly. Would you elaborate on this further? > > > > It seems costly to change the default stack alignment on the platform, > since > > that would require recompiling all of the system and user libraries to > also > > adhere to 32-byte stack

ola, ive been looking at adding support for an -msave-args option for use on x86_64. the short explanation of it is that it makes x86_64 function prologues store their register arguments on the stack. the purpose of this is to make the arguments trivially accessible for things like stack traces with arguments. as per https://blogs.oracle.com/sherrym/entry/obtaining_function_arguments_on_amd64,

Hi everyone, For those who like to play with experimental stuff, I've got something new to test. If you compile with --enable-vorbis-psy , Speex uses a variant of the Vorbis psycho-acoustic model to shape the coding noise. So far, I've obtained a slight increase in quality, but I'm interested in feedback from others. This still needs a lot of tuning and has received only a minimal

+nlewycky On Mon, Nov 17, 2014 at 9:36 AM, Volodymyr Kuznetsov <vova.kuznetsov at epfl.ch > wrote: > Hi Kostya, > > On Sat, Nov 15, 2014 at 1:53 PM, Volodymyr Kuznetsov < > vova.kuznetsov at epfl.ch> wrote: > > Do you think moving the pass to lib/Transform/Instrumentation but > > scheduling it during code generation would make sense ? If so, we'll >

I ran into some odd code being generated today and I came across something that doesn't look quite right. In SelectionDAGBuilder::visitShuffleVector there's some code to see if we can convert the shuffle to an EXTRACT_SUBVECTOR. After computing min/max values of the mask for each operand, there's a look that looks at the ranges and determines whether an EXTRACT_SUBVECTOR can be used:

The selection dag builder has an 'optimization' added into the visitBr function which makes assumptions that are not valid on all architectures. The problem is this. The following function kernel void cf_test(global int* a, int b, int c, int e) { int d = 0; if (!b && c < e) { d = a + b; } *a = d; } Is transformed into something

On Jul 26, 2012, at 12:57 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> +<p>This function returns the same values as the libm <tt>floor</tt> functions >> + would, and handles error conditions in the same way.</p> > > Why the intrinsic then? So that it's possible to access the ISD::FFLOOR SDNode without having to enable a

I posted to llvmdev a few months ago to ask for advice on the best way to avoid the SelectionDAGBuilder from imposing a constraint whereby a volatile load would be serialised relative to all pending loads. The LLVM LRM says that a volatile load only needs to be serialised relative to other volatile loads and, while it may not matter to most targets, the current behaviour of the SelectionDAGBuilder

Hi, I am new to LLVM. I am experimenting with a toy backend. I don't understand "LowerFormalArguments didn't return a valid chain" in SelectionDAGBuilder.cpp file. What is the interface here? What does it mean by returning a Chain? Thanks Jen. -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hey Evan, At the point of the instructions you suggested I step through, X86ISelLowering has this state: - this 0x00000000005fe728 {VarArgsFrameIndex=-842150451 RegSaveFrameIndex=-842150451 VarArgsGPOffset=3452816845 ...} llvm::X86TargetLowering * const + llvm::TargetLowering {TM={...} TD=0x00000000008edac0

Hi Talin, I think that the framework for GC assumes llvm.gcroot to be in the first block. If it is not the case in your example, it will break these assumptions. Nicolas On Sun, Sep 26, 2010 at 1:38 AM, Talin <viridia at gmail.com> wrote: > I'm working on the code to handle GC tracing of "intermediate values" (as > described in the GC doc), and I've run into a

> Yes, I believe that this is happening if any AVX register is used in a > function; an AVX variable does not necessarily need to be placed on the > stack. > > Maybe I am misunderstanding this piece of code though... > >> // Be over-conservative: scan over all vreg defs and find whether >> vector >> // registers are used. If yes, there is a possibility

> Hi everyone, > > For those who like to play with experimental stuff, I've got something > new to test. If you compile with --enable-vorbis-psy , Speex uses a > variant of the Vorbis psycho-acoustic model to shape the coding noise. > So far, I've obtained a slight increase in quality, but I'm interested > in feedback from others. This still needs a lot of tuning

>> When enabling and compiling this with mingw on Win32, my debugger >> complains about heap overruns when calling speex_encoder_destroy(). This >> could be a mingw issue though, as I also found a stackalignment bug which >> prevents me from _USING_SSE (apparantly -mpreferred-stack-size is just >> "prefered" and therefore ignored... *Sigh*). > > Just

I'm working on the code to handle GC tracing of "intermediate values" (as described in the GC doc), and I've run into a weird problem. (Note, this has nothing to do with the patch I have proposed, this error occurs with regular old pointer-allocas.) The exception I am getting occurs in this code here in SelectionDAGBuilder.cpp: *case* *Intrinsic*::gcroot: *if* (GFI) {

I'm trying to track down the problem with the assertion failure in SelectionDAGBuilder.cpp. This is the code: *case* *Intrinsic*::gcroot: *if* (GFI) { *const* Value *Alloca = I.getArgOperand(0); *const* Constant *TypeMap = cast<Constant>(I.getArgOperand(1)); * FrameIndexSDNode *FI = cast<FrameIndexSDNode>(getValue(Alloca).getNode());*

On Mon, Oct 22, 2012 at 5:49 PM, Eric Christopher <echristo at gmail.com>wrote: > > In trunk, the frame pointer is always set up when an AVX register is > used in > > a function. This is done in case 32-byte spill code is later introduced > into > > the function and hence dynamic stack realignment is needed. Needless to > say, > > it's a big hammer. This