similar to: [LLVMdev] Why does x86 fast-isel reject unaligned stores?

On 08/27/2010 11:05, Dale Johannesen wrote: >>>> Function only has on BB. Is this wrong that it has both >>>> TCRETURNri64 and RET in one BB? >>> >>> Yes, that is wrong. The reason emitEpilogue isn't lowering the >>> TCRETURN is that it doesn't see it, it only sees the RET. The real >>> problem will be where that RET is

On 08/27/2010 11:32, Yuri wrote: > As I understand only one of TCRETURNri64 and RET should be created. > I have sources of rev.112200. > > Here is the stack when TCRETURNri64 instruction is created: > #1 0x0000000802c8b4e2 in llvm::MachineFunction::CreateMachineInstr > (this=0x30eb000, TID=@0x803a78940, DL={LineCol = 0, ScopeIdx = 0}, > NoImp=false) at

Hi, LLVM made a change a few months ago and starting erroring out when a float is returned in x64 and SSE is disabled. This makes sense, really, since it's specified by the ABI that the return value must be put in a register you were told to disable, but it's breaking soft floats in Rust on x64. It seems there are two options: LLVM could break the ABI spec and have working soft floats on

Hi All, I want to use Fast Instruction Selection for my X86 back-end. However, my code often uses these two intrinsic functions: x86_sse_movmsk_ps and x86_sse2_pcmpeq_d, which are not supported yet by X86FastISel. Could you guys please show me how to add support for this two Intrinsics? Pointing out one example would be great, I can follow to implement others. I just know that I need to modify

On Aug 27, 2010, at 11:00 AMPDT, Eric Christopher wrote: >>> >>> For some reason I am getting this error even when I only have an >>> empty 'main' function. So I couldn't create .ll file reproducing >>> it and I have to debug myself. >>> >>> The function causing the problem is stub created in >>> JIT::runFunction:

On Aug 27, 2010, at 11:53 AMPDT, Yuri wrote: > On 08/27/2010 11:32, Yuri wrote: >> As I understand only one of TCRETURNri64 and RET should be created. >> I have sources of rev.112200. >> >> Here is the stack when TCRETURNri64 instruction is created: >> #1 0x0000000802c8b4e2 in llvm::MachineFunction::CreateMachineInstr >> (this=0x30eb000, TID=@0x803a78940,

On 08/27/2010 12:13, Dale Johannesen wrote: > I don't think I believe this; emitPrologue should not be generating a > TCRETURN at all, and line 1037 is generating a PROLOG_LABEL. Why do > you say it's a TCRETURN? Sorry, my bad. I have set breakpoints by MI addresses. But it turns out that these addresses were reused and the second MIs created at these particular addressed

Hi everyone, I found that LLVM generates redundant code when calling functions with constant parameters, with optimizations disabled. Consider the following C code snippet: int foo(int x, int y); void bar() { foo(1, 2); foo(3, 4); } Clang/LLVM 6.0 generates the following assembly code: _bar: subl $32, %esp movl $1, %eax movl $2, %ecx movl $1, (%esp) movl $2, 4(%esp) movl %eax, 28(%esp) movl

Hi all, As previously mentioned on this list the Haskell compiler GHC has a new LLVM based back-end. The back-end needs a new calling convention to efficiently use LLVM and that is what this patch does, just for X86 at the moment. Breakdown: 1) Need actual calling convention Touches: - include/llvm/CallingConv.h - lib/Target/X86/X86CallingConv.td 2) Handling new calling

Hello, Is there a script to update those test cases? I see mention of a sed script in the commit message but when I try it (see attached) on sed I get the following error: sed: file script line 2: invalid reference \3 on `s' command's RHS Did I lose something in a copy-paste? Is it not really a sed script? How do I run it? On Fri, Jan 19, 2018 at 9:15 AM, Daniel Neilson via

Sorry I missed that important detail. The relevant part of the command line is: -cc1 -S -triple i386-pc-win32 I don't expect it matters if it's for Windows or Linux in this case. On Fri, Sep 14, 2018 at 9:16 PM David Blaikie <dblaikie at gmail.com> wrote: > Can't say I've observed that behavior (though I'm just building from > top-of-tree rather than 6.0,

Hi Alexandre, The script uses extended-sed syntax, so you need to run sed with the -E option. For example, when preparing the patch I created a file ( script.sed ) containing all of the lines that I copied into the commit message. Then, I ran this bash one-liner from the test directory: for f in $(find . -name '*.ll'); do sed -E -i ‘.sedbak' -f script.sed $f; done When I was happy

Align ip header to a 16 byte boundary to avoid unaligned access like other drivers. Without this patch, xen-netfront doesn't work well on ia64. Signed-off-by: Isaku Yamahata <yamahata at valinux.co.jp> --- drivers/net/xen-netfront.c | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c index 3c3dd40..7416f41

Align ip header to a 16 byte boundary. This patch eliminates noisy warnings on IA64. Signed-off-by: Isaku Yamahata <yamahata at valinux.co.jp> --- drivers/net/xen-netfront.c | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c index 44aed80..2724688 100644 --- a/drivers/net/xen-netfront.c +++

Align ip header to a 16 byte boundary to avoid unaligned access like other drivers. Without this patch, xen-netfront doesn't work well on ia64. Signed-off-by: Isaku Yamahata <yamahata at valinux.co.jp> --- drivers/net/xen-netfront.c | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c index 3c3dd40..7416f41

Align ip header to a 16 byte boundary to avoid unaligned access like other drivers. Without this patch, xen-netfront doesn't work well on ia64. Signed-off-by: Isaku Yamahata <yamahata at valinux.co.jp> --- drivers/net/xen-netfront.c | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c index 3c3dd40..7416f41

This patch adds a feature to allow SSE memops to be unaligned on supported architectures. Mostly I want to see if the naming is reasonable. Supporting unaligned memops requires a bit twiddle on 10h processors. This patch makes the assumption that the OS sets the bit correctly. Comments? -Dave -------------- next part -------------- A non-text attachment was

On 10 September 2012 06:44, Bob Wilson <bob.wilson at apple.com> wrote: > I don't know if anyone actually uses arm processors in big-endian mode, but it shouldn't be too hard to conditionalize it. If it does turn out to be difficult for some reason, we should at least have comments to indicate where the endian assumptions are being made. AFAICR, people used to use big-endian on

If I got you right, this is the classic case for loop peeling. I thought LLVM's vectorizer had something like that already in. On 21 July 2013 18:16, Arnold Schwaighofer <aschwaighofer at apple.com> wrote: > I will have to work on this soon as ARM also has pretty inefficient > unaligned vector loads. > NEON does support unaligned access via VLD*/VST*, what loads are you

This can show up on SPARC or other architectures that don't handle unaligned accesses. The kernel normally fixes these up, but it shouldn't have to. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96836 Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- drm/nouveau/nouveau_bios.h | 6 ++---- drm/nouveau/nvkm/subdev/mxm/mxms.c | 4 ++-- 2 files changed, 4