similar to: [LLVMdev] llc generated assembly does not work with gcc 3.4.4

The ll file: ; ModuleID = 't.bc' target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-f80:128:128-v64:64:64-v128:128:128-a0:0:64-f80:32:32-n8:16:32" target triple = "i686-pc-win32" @.str = private constant [13 x i8] c"hello world\0A\00" ; <[13 x i8]*> [#uses=1] define i32 @main(i32 %argc, i8** %argv)

On Jan 26, 2010, at 6:31 AM, herz wrote: > Hi, > > I've generated a .bc file for a simple program using the clang front > end, the human readable output of llvm-dis looks good. > Running llc on the bc file generates an assembly file (.s using either > att or intel syntax). > Now, when I try to generate an executable with gcc (3.4.4 cygwin) I > get > lot's of

Anton, This is a because the "windows" x86 target defaults to intel syntax asm. I'm not even sure what the "windows" subtarget is if not for mingw or cygwin. Does it make sense to remove the "Windows" target and have "i686-pc-win32" just be a synonym for mingw? -Chris On Jan 27, 2010, at 1:32 AM, herz wrote: > The ll file: > > ; ModuleID

Well, can I enforce gcc compatible output somehow? I tried playing with the llc flags which didn't help. A possible subtarget for windows might be masm, the msvc compiler and the like. Alex Chris Lattner schrieb: > Anton, > > This is a because the "windows" x86 target defaults to intel syntax asm. I'm not even sure what the "windows" subtarget is if not for

Hi, I tried that before, it produces .text ALIGN 16 .globl _main _main: ; @main ; BB#0: ; %entry subl $20, %esp movl $0, 16(%esp) movl 24(%esp), %eax movl %eax, 12(%esp) movl 28(%esp), %eax movl %eax, 8(%esp) movl $($_.str),

> Well, can I enforce gcc compatible output somehow? llc -x86-asm-syntax=att -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

On Jan 28, 2010, at 1:31 AM, Alexander Herz wrote: > Hi, > > I tried that before, it produces Anton, the issue here is the 'isWindows' X86 sub-target. Should it just use the MCAsmInfo values as MingW? -Chris > > .text > ALIGN 16 > .globl _main > _main: ; @main > ; BB#0:

On Mon, Mar 2, 2009 at 2:45 PM, Jonathan Turner <probata at hotmail.com> wrote: > For which version of gcc?  I should mention I'm on OS X and using the LLVM > SVN. gcc 4.3. It's also possible this is processor-sensitive. >> First, try looking at the generated code... the code LLVM generates is >> probably not what you're expecting. I'm getting the

> Date: Mon, 2 Mar 2009 13:41:45 -0800 > From: eli.friedman at gmail.com > To: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Tight overlapping loops and performance > > Hmm, on my computer, I get around 2.5 seconds with both gcc -O3 and > llvm-gcc -O3 (using llvm-gcc from svn). Not sure what you're doing > differently; I wouldn't be surprised if it's

Hi Jeff, > > I notice `lli -print-machineinstrs -x86-asm-syntax=(att|intel)' both > > prefix registers with `%'. Is this right? I thought AT&T did this > > and Intel didn't. The GNU gas manual concurs. > > > > http://www.gnu.org/software/binutils/manual/gas-2.9.1/html_chapter/as_16.html > > The Intel version is just a clone of the

Hi, > It's a long way towards it: > > # AT&T. # Intel. > .text .text > .align 16 .align 16 > .globl main .globl main > .type main, @function > main: main: >

Ok, I got home so I have more details. Here's the sample C program: ----------------- C program --------------- #include <stdio.h> int main() { printf("hello world\n"); return 0; } ------------- end C program ------------- This is compiled using llvm online demo into the following llvm code (target removed): ----------------- LLVM code -------------- deplibs

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,

Vyacheslav, I've tracked down the change and I have a fix for you to test. The attached patch should be applied to the CVS head (version 1.132) of X86AsmPrinter.cpp in llvm/lib/Target/X86. The patch just includes MINGW targets in the same set of choices that it makes for Cygwin. Could you please try the patch and let me know if it solves your problem? If it does, I'll commit the patch.

Hi Duncan, David, Sean. Thanks for your reply. > It'd be interesting if you could find a design that also treated these > the same: > > (B ^ A) | ((A ^ B) ^ C) -> (A ^ B) | C > (B ^ A) | ((B ^ C) ^ A) -> (A ^ B) | C > (B ^ A) | ((C ^ A) ^ B) -> (A ^ B) | C > > I.e., `^` is also associative. Agree with Duncan on including associative operation too.

Vyacheslav, This is the same problem that I had with Cygwin .. nearly identical. The issue was documented in PR492 if you want some background. I'm currently trying to dig up what I did to fix this in December for Cygwin and see if I can apply the same change for mingw. Reid. On Mon, 2005-03-07 at 16:39, Vyacheslav Akhmechet wrote: > Ok, I got home so I have more details. Here's the

Reid, This patch won't work for me. I compile llvm toolset with MSVC Express (hence __MINGW32__ won't be defined for me at compile time). I only try to feed the generated assembly into gcc (pretty much gnu assembler, I suppose). I don't use mingw tools at the earlier stage. However it's obvious for me how to modify the code now (just add MSVC at that line), thanks! I'll try it

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

Thanks Sean for the reference. I will go through it and see if i can implement it for generic boolean expression minimization. Regards, Suyog On Wed, Aug 13, 2014 at 2:30 AM, Sean Silva <chisophugis at gmail.com> wrote: > Re-adding the mailing list (remember to hit "reply all") > > > On Tue, Aug 12, 2014 at 9:36 AM, suyog sarda <sardask01 at gmail.com> wrote:

We know. Someone offered to do the Intel version, but did little more than a huge cut and paste of the AT&T version and then lost interest. No one else has had the time or inclination to finish the (barely begun) job. Patches accepted :) Ralph Corderoy wrote: > Hi, > > >> It's a long way towards it: >> >> # AT&T. # Intel.