similar to: [LLVMdev] Mapping field names to GEP indices in clang-compiled C

On Thu, Mar 26, 2009 at 8:20 AM, Paul Melis <llvm at assumetheposition.nl> wrote: > Hi, > > Slightly off-topic (as it's not directly about using or developing LLVM): > > http://code.google.com/p/unladen-swallow/wiki/ProjectPlan > > "Our long-term proposal is to replace CPython's custom virtual machine > with a JIT built on top of LLVM, while leaving the

Hi, Daniel Berlin wrote: > Then the original reported code is fine, and the bug is in llvm or > llvm-gc (IE Owen is wrong) There is, actually, no problem with this example. I attached it, because it contains some specific programming technique, for which, after instcombining, a weird GEP is generated. I've pasted fragments of generated assembly code below, if someone is interested.

Hi Tanya, On darwin9, the binaries in the darwin10 packages give: $ /opt/clang+llvm-2.7-i386-darwin10/bin/llvm-as --help dyld: unknown required load command 0x80000022 Trace/BPT trap That could be unavoidable, of course. Also, could you document what build mode the packages use (or release both Debug and Release-Asserts packages)? Since +Asserts and -Asserts have different ABIs, I'd have

Hm, I also note that: $ file /opt/clang+llvm-2.7-i386-darwin10/bin/llvm-as /opt/clang+llvm-2.7-i386-darwin10/bin/llvm-as: Mach-O 64-bit executable x86_64 Why's the i386 package have an x86_64 binary in it? That could explain why it doesn't work on darwin9. On Fri, Mar 19, 2010 at 9:49 AM, Jeffrey Yasskin <jyasskin at google.com> wrote: > Hi Tanya, > > On darwin9, the

Greetings all, Every now and then, as we engage in serious discourse, it seems appropriate to throw something into the mix that might digress and brighten the day. So, what is a Strouhal Number? "For an animal or insect in flight, the Strouhal number is determined by the frequency (f) of wing strokes, multiplied by the amplitude (A) of the wing, divided by the animal?s forward speed (U)

Hello Duncan, > thanks for your interesting email. Do you understand why PyPy is no longer > using LLVM, and why Unladen Swallow died? Does LLVM need to be improved in > some way? The answers to all these questions are linked: LLVM is not fast enough (for a JIT). Of course this is not the whole story, but it is the LLVM-relevant part. Let's have a look at some random performance

Hi Chris & Evan, On Sun, Jul 13, 2008 at 03:34:03PM -0700, Chris Lattner wrote: > Why? What value does that provide? Struct indices are not allowed to > be variable, so picking any width constant (that isn't too small) is > fine. What problem are you trying to solve here? The current code only allows 32 bit constants. My patch allows any width constant to be used, but it

The only VHDL to LLVM project that I know of is nvc. [0] I haven't tried it personally and from a cursory look through the source it seems like there is a LLVM backend and a "native" backend (not sure what that means). If you're really crazy you might want to see if you could massage GHDL [1] (VHDL GCC frontend) + DragonEgg [2] (LLVM backend for GCC) to get you LLVM IR. I'm

Hi all, I just found that TargetData also contains a similar assert, and that I forgot a "return" in my previous patch. Here's an updated patch, which allows to use any integer to index a CompositeType. It seems this enables GEP to work with any integer value as well, I tested indexing a struct with a i16 an i64 (also through llc). This should still be adressed somewhere, unless we

Not sure, but it seems the page contains a number of out-of-date entries: Pypy => pypy.org (link stale) plus: there is no llvm backend for pypy at the moment (although LLVM backends have been attempted a number of times, all seem to have failed) Unladen Swallow => not being developed since 2011 (http://qinsb.blogspot.com/2011/03/unladen-swallow-retrospective.html) TIA, Andreas The

On Wed, Jul 15, 2009 at 2:24 PM, Albert Graef<Dr.Graef at t-online.de> wrote: > Owen Anderson wrote: >> On Jul 15, 2009, at 10:56 AM, Jean-Daniel Dupas wrote: >>> >>> You mean like this subject ? >>> >>> http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-June/023505.html >> >> Notice the sender line on that email... ;-) > > Yes, you

Thanks for the report. The attached patch removes them from the page. OK? On 8 May 2013 11:34, Kostyrka (External user) Andreas <Andreas.Kostyrka at kapsch.net> wrote: > Not sure, but it seems the page contains a number of out-of-date entries: > > > > Pypy => pypy.org (link stale) plus: there is no llvm backend for pypy at the > moment (although LLVM backends have been

Hi Travis, ... > LLVM is still very relevant to Python because of projects like Numba --- but you > should know that PyPy is no longer using LLVM and Unladen Swallow has not been > worked on for several years. The future of LLVM and Python I think is very > bright --- especially for the scientific and data-analysis user-base. thanks for your interesting email. Do you understand

I have a little simple inheritance thing going on: %struct.PDFrame = type { i64, i64, i8* } %struct.PDField = type { %struct.PDFrame, i8 } Is there any difference between bitcasting a pointer to the struct.PDField to struct.PDFrame, or using GEP to get a pointer to the "super" struct? I'm not even sure it's possible to bitcast in this situation, but I imagine it should be. --

In Unladen Swallow we (intend to) compile each function as we determine it's hot. To "compile" a function means to translate it from CPython bytecode to LLVM IR, optimize the IR using a FunctionPassManager, and JIT the IR to machine code. We'd like to include inlining among our optimizations. Currently the Inliner is a CallGraphSCCPass, which can only be run by the

Hi Evan, > I don't think this is right. According to llvm documentation: > > The index types specified for the 'getelementptr' instruction depend on the > pointer type that is being indexed into. Pointer and array types can use a > 32-bit or 64-bit integer type but the value will always be sign extended to > 64-bits. Structure and packed structure types require

On Sat, Jan 24, 2015 at 5:44 PM, Chandler Carruth <chandlerc at google.com> wrote: > > On Tue, Jan 20, 2015 at 12:27 PM, Ahmed Bougacha <ahmed.bougacha at gmail.com > > wrote: > >> Hi all, >> >> This is covered by (struct-path aware) TBAA, but BasicAA disagrees. >> See the attached testcase, where it prevents us from removing the >> redundant

Sadly, this will break a very common idiom. In GCC, we discovered it to be common enough that it broke a *bunch* of C code. In particular, you will break struct foo { int a; char name[0]; } bar = malloc(sizeof (struct foo) + strlen("thisismyname") + 1); strcpy(bar->name, "thisismyname"); It only started turning up when we started doing higher level loop opts and used

Duncan, Thanks for the quick review! Here is a short description (design) of where I am going with this patch: 1. Motivation: Vectors-of-pointers is the first step in supporting scatter/gather instructions (available in AVX2, for example). I believe that this feature was requested on the mailing list before. As mentioned by Hal Finkel earlier today, this feature is desired by autovectorizers as

It's an optimization opportunity! When behavior is undefined, we're free to interpret it to be "whatever makes optimization easiest." If the two do actually happen to alias, well, it's the programmer's fault anyways, because they were doing something undefined! --Owen On Nov 13, 2007, at 4:13 PM, Wojciech Matyjewicz wrote: > Hi! > > While investigating