search for: sicherha

...s for > liveness. > > > > However, the backend is not optimizing these calls away. I could try to > deal with them outside of llvm but I was hoping for a cleaner solution > using llvm? > > > > On Mon, Mar 5, 2012 at 11:51 AM, Christoph Erhardt < > christoph at sicherha.de> wrote: > > Hi Ryan, > > > > the compiler is free to insert implicit calls to memcpy(), for instance > > for assignments from one struct/class variable to another. The same goes > > for memset(), which may be inserted implicitly for the initialization of > &gt...

...you are correct on the lifetime calls, they are just markers for liveness. However, the backend is not optimizing these calls away. I could try to deal with them outside of llvm but I was hoping for a cleaner solution using llvm? On Mon, Mar 5, 2012 at 11:51 AM, Christoph Erhardt <christoph at sicherha.de>wrote: > Hi Ryan, > > the compiler is free to insert implicit calls to memcpy(), for instance > for assignments from one struct/class variable to another. The same goes > for memset(), which may be inserted implicitly for the initialization of > local structs or arrays. &gt...

...they are just markers for liveness. > > > > However, the backend is not optimizing these calls away. I could try to deal with them outside of llvm but I was hoping for a cleaner solution using llvm? > > > > On Mon, Mar 5, 2012 at 11:51 AM, Christoph Erhardt <christoph at sicherha.de> wrote: > > Hi Ryan, > > > > the compiler is free to insert implicit calls to memcpy(), for instance > > for assignments from one struct/class variable to another. The same goes > > for memset(), which may be inserted implicitly for the initialization of > &gt...

...he lifetime calls, they are just markers for liveness. > > However, the backend is not optimizing these calls away. I could try to deal with them outside of llvm but I was hoping for a cleaner solution using llvm? > > On Mon, Mar 5, 2012 at 11:51 AM, Christoph Erhardt <christoph at sicherha.de> wrote: > Hi Ryan, > > the compiler is free to insert implicit calls to memcpy(), for instance > for assignments from one struct/class variable to another. The same goes > for memset(), which may be inserted implicitly for the initialization of > local structs or arrays. &g...

Hi Mikael, > My Clang build used to take 59:29 minutes using MinGW Makefiles. With > Ninja, it takes 18:43 minutes! That's a speed up of factor three. sorry for asking the obvious question: Are you comparing against a parallel "make -j<n>"? :-) Best regards, Christoph

...? Since the new instruction would produce the same context/result of the old one, I suppose it is safe to remove the old one when the new instruction is ready (inserted after the old one). Anything I missed here? Thanks, -Thomson On Mon, Jun 18, 2012 at 7:31 PM, Christoph Erhardt <christoph at sicherha.de>wrote: > Hi Thomson, > > > Ok. So it seems CI->eraseFromParent() removed the old instruction and > > the new one is inserted right after this one in the inner function in > > the case of printf->puts. There is another line > > CI->repalceAllUsesWith(Res...

Christoph Erhardt <christoph at sicherha.de> writes: > Hi Mikael, > >> My Clang build used to take 59:29 minutes using MinGW Makefiles. With >> Ninja, it takes 18:43 minutes! That's a speed up of factor three. > sorry for asking the obvious question: Are you comparing against a > parallel "make -j&lt...

Hi, Ninja is being mentioned more and more frequently on this list, but I don't think anybody has introduced it formally. Ninja is, briefly put, a super-fast replacement for GNU Make, nmake, and all the other make tools out there. For those of you who are a bit reluctant to waste time on Ninja or don't know what it is, I can strongly urge you to download it from

...sult). I think this line could also do the replacement besides inserting the new one in the inner function. What's the difference of these 2 replacement methods? Also thanks for your reminder of CC the mailing list. -Thomson On Mon, Jun 18, 2012 at 4:08 PM, Christoph Erhardt <christoph at sicherha.de>wrote: > Hi Thomson, > > the new call to puts() is inserted right away, whereas the old call to > printf() is removed a bit later in SimplifyLibCalls::runOnFunction(). If > you browse the code a bit and backtrack the call stack to see what > happens with the return value of...

...markers for liveness. >>> >>> However, the backend is not optimizing these calls away. I could try to deal with them outside of llvm but I was hoping for a cleaner solution using llvm? >>> >>> On Mon, Mar 5, 2012 at 11:51 AM, Christoph Erhardt <christoph at sicherha.de> wrote: >>> Hi Ryan, >>> >>> the compiler is free to insert implicit calls to memcpy(), for instance >>> for assignments from one struct/class variable to another. The same goes >>> for memset(), which may be inserted implicitly for the initializa...

...t;> > >>> However, the backend is not optimizing these calls away. I could try > to deal with them outside of llvm but I was hoping for a cleaner solution > using llvm? > >>> > >>> On Mon, Mar 5, 2012 at 11:51 AM, Christoph Erhardt < > christoph at sicherha.de> wrote: > >>> Hi Ryan, > >>> > >>> the compiler is free to insert implicit calls to memcpy(), for instance > >>> for assignments from one struct/class variable to another. The same > goes > >>> for memset(), which may be inserted...

Hello there, I recently started working on the LLVM backend for a target that doesn't support x87 instructions. Currently, I am in the process of completely disabling some x87 instructions such as fcomi, fcompi,... for a specific sub-target. I also do not have SSE enabled for my sub-target, and llvm resorts to fcomi* instructions for FP compare instructions. Is there a way to bypass the

Hi Ryan, the compiler is free to insert implicit calls to memcpy(), for instance for assignments from one struct/class variable to another. The same goes for memset(), which may be inserted implicitly for the initialization of local structs or arrays. The good news is that the backend normally optimizes these calls away where possible, replacing them with simple moves - at least as long as the

...> > > > > > However, the backend is not optimizing these calls away. I could try > to deal with them outside of llvm but I was hoping for a cleaner solution > using llvm? > > > > > > On Mon, Mar 5, 2012 at 11:51 AM, Christoph Erhardt < > christoph at sicherha.de> wrote: > > > Hi Ryan, > > > > > > the compiler is free to insert implicit calls to memcpy(), for instance > > > for assignments from one struct/class variable to another. The same > goes > > > for memset(), which may be inserted implicitly for...

Thanks Chris, your response has been very helpful so far. I will try your solution, as opposed to the one that I have right now. (Disabling all the x87 instructions altogether). Yours, Ram -----Original Message----- From: Christoph Erhardt [mailto:christoph at sicherha.de] Sent: Thursday, April 05, 2012 7:08 PM To: Murali, Sriram Subject: Re: [LLVMdev] Disabling x87 instructions for a sub-target Hi Ram, of course I can share the patch with you as soon as I have put it up for review. As far as I'm aware, the bugfix should be relatively version-agnostic, so...

Hi Thomson, > Ok. So it seems CI->eraseFromParent() removed the old instruction and > the new one is inserted right after this one in the inner function in > the case of printf->puts. There is another line > CI->repalceAllUsesWith(Result). I think this line could also do the > replacement besides inserting the new one in the inner function. What's > the difference

Hi Thomson, > Could you give an example of the old instruction cannot be removed > safely? Since the new instruction would produce the same context/result > of the old one, I suppose it is safe to remove the old one when the new > instruction is ready (inserted after the old one). Anything I missed here? yes, you're missing that LLVM programs are in SSA form: A new instruction

...struction doesn't make any assignment, it would be unnecessary to replace any operand reference and the same instruction(CI) would be returned from the inner function to avoid this replacement, is this right? Thanks, -Thomson On Mon, Jun 18, 2012 at 8:09 PM, Christoph Erhardt <christoph at sicherha.de>wrote: > Hi Thomson, > > > Could you give an example of the old instruction cannot be removed > > safely? Since the new instruction would produce the same context/result > > of the old one, I suppose it is safe to remove the old one when the new > > instruction...

Hi, I would like to know what register scavenging is, but reading RegisterScavenging.h [1] and googling don't help too much. Could someone explain it a little bit (what it is and when we need it), or point me to some nice link, I will be very appreciated. :-) [1] http://llvm.org/docs/doxygen/html/RegisterScavenging_8h_source.html Regards, chenwj -- Wei-Ren Chen (陳韋任) Homepage:

...artine.github.com/ninja/ Yes, I am quite familiar with the CMake documentation, but why are you asking? I use CMake all the time for my MinGW32 and MinGW64 builds. Now I use "CMake -G Ninja" :-) 2012/6/18 Óscar Fuentes <ofv at wanadoo.es> > Christoph Erhardt <christoph at sicherha.de> writes: > > > Hi Mikael, > > > >> My Clang build used to take 59:29 minutes using MinGW Makefiles. With > >> Ninja, it takes 18:43 minutes! That's a speed up of factor three. > > sorry for asking the obvious question: Are you comparing against a &...