similar to: [LLVMdev] LLVM Newb: Getting started

Hi Wolfgang, On Thu, 2006-11-23 at 19:47 +0100, Wolfgang Draxinger wrote: > A few days ago Craig Black made the suggestion in the D newsgroup, > that someone creates a D <http://www.digitalmars.com/d/index.html> > frontend for LLVM. Never having heard of LLVM in the past, I > immediately got captured by its design when I've read the > documentation. I was always

A few days ago Craig Black made the suggestion in the D newsgroup, that someone creates a D <http://www.digitalmars.com/d/index.html> frontend for LLVM. Never having heard of LLVM in the past, I immediately got captured by its design when I've read the documentation. I was always scared by GCC - a great piece of software, but horribly bad documented, and in it's own way not very

I tried the version you used, too. the resulting executable was still broken. I guess the reason is due to fastcall on function pointers, which Clang does not recognize. Consider the following snippet. #include <stdio.h> void __attribute__((fastcall)) f(int i) { printf("%d\n", i); } typedef void (*__attribute__((fastcall)) f_t)(int i); //typedef void

On Mar 11, 2013, at 9:41 AM, Nadav Rotem <nrotem at apple.com<mailto:nrotem at apple.com>> wrote: Hi Richard, I did… It originates from an icmp ne <2x i8>, zero initializer followed by a sext of the result 2x i1 to 2x i8. When we visit the SIGN_EXTEND, we generate the ISD::SELECT even though the selector and both operands are vectors. It sounds like a bug in the dag combine

> > Line 4501 in trunk DAGCombiner.cpp… I changed the ISD::SELECT to the VT.isVector() ? ISD::VSELECT : ISD::SELECT... > Thanks. From the commit message I think that we should only run this optimization on scalars. >> Can you write down the input SDNode ? What types are inputs ? > > 0x107046d10: v2i8 = vselect 0x107046c10, 0x107046b10, 0x107045e10 [ID=-3]

Dale, > The user can specify the "fastcall" and "stdcall" attributes, and it > looks to me like llvm-gcc honors that. Certainly it should. fastcall and stdcall are specific calling conventions. They are not connected with fastcc at all. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

If you mark VSELECT as 'expand' then it will be expanded to a sequence of AND/OR/XOR, which is pretty efficient (found in LegalizeVectorOps.cpp ExpandVSELECT). On Oct 11, 2012, at 11:05 AM, Jim Grosbach <grosbach at apple.com> wrote: > Seems reasonable to me. Plain 'SELECT' is already marked expand for vector types. I bet that just didn't get updates when VSELECT

Hello, Wolfgang. > I did not manage to make llvm-gcc create __main. Code for static construction & destruction is highly platform dependent. Usually it's placed in crt.o binary, which is compiled during main gcc build cycle. For example, for Linux we should only output some code in specialy named sections and this code will automatically called by system loader. As opposite, for

Seems reasonable to me. Plain 'SELECT' is already marked expand for vector types. I bet that just didn't get updates when VSELECT was introduced. -Jim On Oct 11, 2012, at 10:25 AM, Peter Couperus <peter.couperus at st.com> wrote: > Hello, > > We've run into a couple of cases where we'd like to use select on vector types, but vselect handling is absent from

I''m trying to follow the videos over on http://www.loudthinking.com/arc/000328.html. The first bit of it was fine, but then it says to type "ruby script \new_controller Hello index". My scripts folder doesn''t contain anything even similar to "new_controller". According to the generated "index.html" page, it says "Use script/generate to create

On Mar 8, 2013, at 2:29 PM, Nadav Rotem <nrotem at apple.com<mailto:nrotem at apple.com>> wrote: Hi Richard, visitSIGN_EXTEND() in DAGCombiner.cpp generates an ISD::SELECT even if VT is a vector, which causes ExpandSELECT() to assert during legalization. I think what's required is to have visitSIGN_EXTEND generate a VSELECT if VT is a vector… ISD::SELECT should be used for

Hi Richard, > visitSIGN_EXTEND() in DAGCombiner.cpp generates an ISD::SELECT even if VT is a vector, which causes ExpandSELECT() to assert during legalization. > I think what's required is to have visitSIGN_EXTEND generate a VSELECT if VT is a vector… ISD::SELECT should be used for cases where the selector is a scalar, even if the operands are vector. If you found a case where SELECT

Hi JinGu Kang, On 28/05/13 17:18, jingu kang wrote: > Hi all, > > I met the error while compiling the code with vector type with some > architecture. IR is as following. > > %cmp = icmp sgt <3 x i8> %x, zeroinitializer > %sub = sub <3 x i8> zeroinitializer, %x > %cond = select <3 x i1> %cmp, <3 x i8> %x, <3 x i8> %sub > >

Can this optimization be moved to the lowering phase? LowerVSELECT() ? - Elena From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Eli Friedman Sent: Tuesday, August 20, 2013 03:56 To: Juergen Ributzka Cc: Benjamin Kramer; LLVM Developers Mailing List Subject: Re: [LLVMdev] [X86] DAG Combine - VSELECT On Mon, Aug 19, 2013 at 4:17 PM, Juergen

I'm trying to understand the LLVM calling conventions. Coming from a Windows C++ background, I'm familiar with three calling conventions: cdecl, stdcall, and fastcall. It looks like cdecl corresponds to ccc in LLVM, but I'm not sure about the other two. Best Regards, Jon

Hi all, I met the error while compiling the code with vector type with some architecture. IR is as following. %cmp = icmp sgt <3 x i8> %x, zeroinitializer %sub = sub <3 x i8> zeroinitializer, %x %cond = select <3 x i1> %cmp, <3 x i8> %x, <3 x i8> %sub 'select' IR is converted to 'vselect' dag and is combined to 'sra (X, size(X)-1); xor

The latest release of the CIL C frontend (http://sf.net/projects/cil) now includes a module to generate LLVM assembly code from CIL's intermediate format. It should be considered alpha-level code and still has a number of significant limitations: It is targeted to the 32-bit mode of x86 processors using gcc's C dialect. It handles all of C, except: - bitfields - inline

Hello, We've run into a couple of cases where we'd like to use select on vector types, but vselect handling is absent from the ARM backend. Would there be any potential harm by marking VSELECT as Expand on ARM targets with NEON? Adding this seems to fix the following PR's: http://llvm.org/bugs/show_bug.cgi?id=13831 http://llvm.org/bugs/show_bug.cgi?id=13961 Thanks! Pete

Hi @ll, I am wondering about the use of !isBeforeLegalize in PerformSELECTCombine in the X86 backend. This defers all VSELECT related DAG combines until after the Legalizer has run. If the IR has already only legal types the second round of DAG combines is skipped and no VSELECT specified optimizations are performed at all. Is there a reason we don’t run the X86 DAG combiner before Type

Am Freitag, 24. November 2006 03:00 schrieb Reid Spencer: > If you're making your own front end, you probably won't need it :) Well, I wanted to play around with it, so see, how my older programs perform with it. So far I managed to get some programs running by folowing scheme: for src in $infiles; do llvm-gcc -o $src.bc -c $src ; opt -f -o $src.bc.opt $src.bc ; llc -f $src.bc.opt