similar to: [LLVMdev] Kinda noob questions

On 3/14/11 7:52 PM, Judison wrote: > Hi all, > > I have 2 simple questions... > > First, just for you to know, I'm making a compiler (kinda obvious) and > the language definition is mine, so there is no much constraint for > me, it's written in Java (it generates a .ll file as output) and it's > just for fun by now, maybe a serious project after I learn all

On Mar 14, 2011, at 5:56 PM, John Criswell wrote: > On 3/14/11 7:52 PM, Judison wrote: >> >> 2) does the LLVM optimizes this: >> >> ; this code (arg -> var) is very similar to what gcc generates >> define void @foo(i32 %arg0) { >> entry: >> %var0 = alloca i32 >> store i32 %arg0, i32* var0 >> ... >> %x = load i32*

Thank you John and John :P these optimizations (mem2reg and the "few additional" ones) I have to enable then or something like this?? (I compile the .ll to .o with the sequence llvm-as, llc, as) Yet about dynamic stack allocation, what is (generally) better? to pre alloc everything at start, or let it be? Imagine this pseudo-code while (x) { int b = 0; ... } using alloca where b

Hi, I hope this is the right place to ask it, sorry if I'm wrong... My compiler is generating this code: (line numbers included) (Please ignore the extra br label %b0 and the whole b0) ... 54 define i32 @std_lang__rest() { 55 entry: 56 %ret = alloca i32 ; <i32*> int* 57 %0 = icmp eq i32 4, 5 ; <i1> boolean 58

On Fri, Mar 11, 2011 at 11:48 AM, Judison <judison at gmail.com> wrote: > I hope this is the right place to ask it, sorry if I'm wrong... It's the right place, though the IRC channel would have been good too. > My compiler is generating this code: > > (line numbers included) (Please ignore the extra br label %b0 and the whole > b0) Sorry, but the extra branches

Thanks everyone for your answers. Mats, my goal is do an alternate implementation of the subtyping test in the Pony compiler. I'll try to keep the explanation short to avoid cluttering the mail with irrelevant information. Every object in Pony has a type descriptor, which is used in the subtyping test to determine the real type of an object. The current algorithm is suboptimal and

Hi. First of all, some context. I'm trying to implement a new functionality in an LLVM-based compiler and I need to take various actions based on the value of a given pointer, the possible values being the addresses of various global constants. I tried to use a `switch` instruction but I encountered several problems. The "ideal switch" I'd like to have would look

Hi R-users, I'm trying to retrieve data from MS SQL database with RODBC's sqlQuery-function: temp <- sqlQuery(channel,"select *, (select text from table1 where koodi='paa' and koodi2=paa) as tempor from table2") str(temp) … $ var0 : num NA NA 1.6 NA NA 1.4 NA 1 NA NA ... $ var1 : Factor w/ 45 levels "

Hi, I was tracking down a performance regression and noticed that LoopStrengthReduce hoists loop invariants (e.g., the initial formulae of indvars) in the reverse order of how they appear in the loop. This reverse order creates troubles for the StraightLineStrengthReduce pass I recently add. While I understand ultimately SLSR should be able to sort independent candidates in an optimal order,

The loads, stores and float arithmetic in attached function should be completely vectorizable. The bb-vectorizer does a good job at first, but from instruction %96 on it messes up by adding unnecessary vectorshuffles. (The function was designed so that no shuffle would be needed in order to vectorize it). I tested this with llvm 3.6 with the following command:

I have a probe: pid111::myfunc:entry { self->arg = arg0; } pid111::myfunc:return /self->arg/ { @[self->arg] = quantize(); } works great, but i''d like arg0 to be printed in hex. I''ve tried numerous approaches to do this but i''ve hit a wall every time. I''ve tried: 1) self->arg = sprintf(arg0); no, cuz dtrace has no sprintf 2) self->arg

Howdy, I was playing around with the malloc/free D script provided by Philip Beevers: http://www.opensolaris.org/jive/thread.jspa?threadID=4224&tstart=15 And decided to change the free:entry probe from: pid24169::free:entry / sz[arg0] / { printf("Freeing %p (size %d)\n", arg0, sz[arg0]); sz[arg0] = 0; } to: pid24169::free:entry / ! sz[arg0] / { printf("[ *

Hi, I ran a d-program with syscall::open:entry probe but got the following error messages sometimes: dtrace: error on enabled probe ID 1 (ID 14: syscall::open:entry): invalid address (0xff34e000) in predicate at DIF offset 76 dtrace: error on enabled probe ID 6 (ID 14: syscall::open:entry): invalid address (0xff34e000) in predicate at DIF offset 28 I don''t know how to interpret these

I seem to have problem to get the SLP vectorizer to make use of the full 8 floats available in a SIMD vector on a Sandy Bridge CPU with AVX. The function is attached, the CPU flags are: flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good

Dear dtrace Experts, I have seen some dtrace utilities like opensnoop and execsnoop etc. My interest is to write a simple script that can snoop the files which uses the 3 syscalls like open,create,unlink. I have gone through dtrace oneliners that can do the same : dtrace -n ''syscall::open*:entry { printf("%s %s",execname,copyinstr(arg0));}'' dtrace -n

Hello, I am trying to reach a web service using the SOAP package. I succeeded calling the web service, but not sending parameters to it. After much research and tries, I think I found that the problem lies in the namespace including the parameters in the SOAP body. In short, my question is: how can I send unqualified parameters in the SOAP body of a call produced through the SOAP package?

Hi all, Is there a way to express in the IR that a pointer's value is a multiple of, say, 32 bytes? I.e. the data the pointer points to has an alignment of 32 bytes. I am not meaning the natural alignment determined by the object's size. I am talking about a double* pointer and like to explicitly overestimate the alignment. I am trying to add this pointer as a function's

Hi all, OK, so this at first looked like a clear cut "Don''t do it, or at worst handle the results" issue my customer has come to me with, but the more we discuss it, the more it looks like we should have better ways of dealing with this issue. > We have user defined dtrace probe points in the application which use > as parameter 64 bit values: > > provider adv {

With dtrace, I can use function arguments in the form of arg0, arg1, etc, as indices into an "associative" array. If all that an array takes as an index is an int64_t, is there any reason for dtrace to require me to have an explicit type conversion in there rather than having it do it for me automatically? At present I need to do: mblks[arg0] or mblks[(int64_t)((mblk_t

Whilst trying out some D to get an insight into what is the most common reason for a given function to return, I have bumped into an error I don''t understand. The first take on what I was trying to do was: # dtrace -n ''fbt:ip:ip_input:return{@home[arg0] = count();}'' and all was well. The next step was: # dtrace -n