search for: erhardt

...ime 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 fo...

Christoph, Yes, 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 > lo...

...ct 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...

...Yes, 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 > l...

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

...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? 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-...

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 >...

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

...>repalceAllUsesWith(Result). 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 > happen...

...time 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 imp...

...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...

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 everyone, I am currently working on a backend for the TriCore architecture. Unfortunately, I have hit an issue with LLVM's internal representation that's giving me a bit of a headache. The problem is that LLVM assumes that a pointer is equivalent to a machine-word sized integer. This implies that all pointer arithmetic takes place in the CPU's general-purpose registers and is done

Hi Christoph I am compiling for x86-64. This error happens randomly (at least it appears that way) and rarely. About every few thousand runs -- Regards, Gabi http://bugspy.net

Hi Gabi, the only useful advice I can give you right now: Try to narrow the problem down. You'll have to find out where the "problematic" constant 3.540000e+02 comes from and boil it down into a test case. Regards, Christoph

Hi Micah, the register use list gets dropped by the instruction selector because you didn't specify "variable_ops" in the input operand list of your CALL instruction. It has to look like this: (ins calltarget:$dst, variable_ops) Regards, Christoph

Hi Andreas, > In practice that'll mean adding the correct directives to > CMakeLists.txt, not Makefile, right? That's what the targets I looked > at did. LLVM can be built using either CMake or the GNU Autotools. Your backend ought to provide support for both build systems, so you should create a CMakeLists.txt as well as a Makefile in your sub-directory. The Makefile appears

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

...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...

Hi Patrik, > DAG.getMachineFunction().getFunction() only works in LowerFormalArguments (there it returns the callee), not in LowerCall (where it returns the caller, rather than the callee). You need to pass more information about the function type to LowerCall (besides partial information such as the isVarArg parameter). > > I can provide a patch if you are interested. (Unfortunately,