similar to: [LLVMdev] Opt pass for collecting static memory allocations (allocas and globals) to one big memory area.

On 3/11/13 6:32 AM, Mikael Lepistö wrote: > Hi, > > I'm doing llvm pass for OpenCL code which does some memory checking to > verify that code does not access memory outside of the programs own > statically allocated areas. If you're looking to see if your program only accesses in-bounds memory, SAFECode and Address Sanitizer may be able to do this for you already. If

Hi, Would it be possible to set tbgen to be installed with llvm? For our project http://llvm.org/ProjectsWithLLVM/#tta-tce it would be very helpful, because our tools generate compiler backend plugins in the fly for each customized processor and plugin generation needs tbgen for handling td files. Because of tbgen not beeing distributed, our users cannot use llvm from their favorite

On May 4, 2009, at 11:03 PM, Mikael Lepistö wrote: > Hi, > > Would it be possible to set tbgen to be installed with llvm? For our > project http://llvm.org/ProjectsWithLLVM/#tta-tce it would be very > helpful, because our tools generate compiler backend plugins in the > fly for each customized processor and plugin generation needs tbgen > for handling td files. Sure,

Chris Lattner wrote: > > On May 4, 2009, at 11:03 PM, Mikael Lepistö wrote: > >> Hi, >> >> Would it be possible to set tbgen to be installed with llvm? For our >> project http://llvm.org/ProjectsWithLLVM/#tta-tce it would be very >> helpful, because our tools generate compiler backend plugins in the >> fly for each customized processor and plugin

Hi, I was talking with aKor in #llvm how we could implement custom operation support for our ASIP architecture. We came into solution that the best way would be to write new custom operation intrinsic and optimization pass for raising certain type of function calls to those intrinsics (similar to raising mallocs). Basically our custom operation are like calls, with operand name and multiple

Hi, I've been hitting my head to wall two days now. This is practically my first contact with InstrInfo.td files. Is there any tutorial how to make this kind of stuff? Or should I just keep on studying Sparc and other backends? So I added new intrinsic to llvm/include/llvm/TCEInstrinsics.td: def int_tce_customop : Intrinsic<[llvm_void_ty, llvm_ptr_ty, llvm_vararg_ty], [],

Hi, Anybody has an opinion would it be good thing to add support for llvm- gcc to be able to be built with existing llvm installation? Right now building works with llvm installation also, but only if llvm libs and includes are installed under the same prefix, even though this seems to be unintended functionality. So after support for building llvm-gcc without llvm sources it would be

Chris Lattner wrote: > On Tue, 31 Jul 2007, [ISO-8859-1] Mikael Lepist� wrote: >> I was talking with aKor in #llvm how we could implement custom operation >> support for our ASIP architecture. We came into solution that the best >> way would be to write new custom operation intrinsic and optimization >> pass for raising certain type of function calls to those intrinsics

Chris Lattner wrote: > On Wed, 1 Aug 2007, [UTF-8] Mikael Lepist? wrote: > >>> def MOVNTPSmr : PSI<0x2B, MRMDestMem, (outs), (ins i128mem:$dst, >>> VR128:$src), >>> "movntps {$src, $dst|$dst, $src}", >>> [(int_x86_sse_movnt_ps addr:$dst, VR128:$src)]>; >>> >>> There is corresponding code in llvm-gcc to tell GCC how to

> From: Mikael Lepist? <mikael.lepisto at tut.fi> > > Hi, Hi Mikael > I was talking with aKor in #llvm how we could implement custom operation > support for our ASIP architecture. We came into solution that the best > way would be to write new custom operation intrinsic and optimization > pass for raising certain type of function calls to those intrinsics > (similar

On Wed, 1 Aug 2007, [UTF-8] Mikael Lepist? wrote: >> def MOVNTPSmr : PSI<0x2B, MRMDestMem, (outs), (ins i128mem:$dst, >> VR128:$src), >> "movntps {$src, $dst|$dst, $src}", >> [(int_x86_sse_movnt_ps addr:$dst, VR128:$src)]>; >> >> There is corresponding code in llvm-gcc to tell GCC how to handle this >> builtin. Is this what you're

Hi Pekka, > To put it the another way: is there a reason to disallow > compiling llvm-gcc (optionally) against an installed LLVM (e.g. > from the Debian package)? It seems to work fine with this patch > Mikael posted. I think it would be great if llvm-gcc could be built against an installed LLVM. However my impression was that Mikael's original patch would break building against

On 15.9.2009, at 12:11, Duncan Sands wrote: > Hi Pekka, > >> To put it the another way: is there a reason to disallow >> compiling llvm-gcc (optionally) against an installed LLVM (e.g. >> from the Debian package)? It seems to work fine with this patch >> Mikael posted. > > I think it would be great if llvm-gcc could be built against > an installed LLVM.

On Tue, 31 Jul 2007, [ISO-8859-1] Mikael Lepist� wrote: > I was talking with aKor in #llvm how we could implement custom operation > support for our ASIP architecture. We came into solution that the best > way would be to write new custom operation intrinsic and optimization > pass for raising certain type of function calls to those intrinsics > (similar to raising mallocs). >

Boris, > Yes, I know that. configure --target=a-b-c will fail because there > is no such stuff known in gcc. So, what is the answer/consequence? An > existing gcc back-end for architecture "a" is a precondition for a > LLVM back-end for architecture "a"? No. This is requirement of using gcc as a frontend. This looks pretty weird, but it is: frontend should

Hi, We have been working on porting llvm-gcc crosscompiler (basically I had to create new dummy target configuration with some minimal information about the our processor, endianess, type sizes, etc.) which compiles llvm bytecode (doesn't compile native binaries nor assembler) for our processor architecture and new llvm target for our custom processor. We already managed to compile also

Mikael Lepistö wrote: > On 15.9.2009, at 12:11, Duncan Sands wrote: > > >> Hi Pekka, >> >> >>> To put it the another way: is there a reason to disallow >>> compiling llvm-gcc (optionally) against an installed LLVM (e.g. >>> from the Debian package)? It seems to work fine with this patch >>> Mikael posted. >>>

Mikael Lepistö wrote: > Anybody has an opinion would it be good thing to add support for > llvm-gcc to be able to be built with existing llvm installation? To put it the another way: is there a reason to disallow compiling llvm-gcc (optionally) against an installed LLVM (e.g. from the Debian package)? It seems to work fine with this patch Mikael posted. For us at TCE project* it's a

Hi all, Thanks for the answers! I feel like I've hijacked your thread now though Björn, sorry for that. But from the answers it sounds like there is agreement that it's reasonable to remove the duplicates as done in Björn's patch? --- A couple of more things around the problem I saw. On 09/19/2017 05:40 PM, Adrian Prantl wrote: > A dbg.declare describes a stack-allocated

> On Sep 19, 2017, at 8:44 AM, Reid Kleckner <rnk at google.com> wrote: > > On Tue, Sep 19, 2017 at 8:40 AM, Adrian Prantl via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Later loop unroll comes and unrolls the loop and then suddenly we have two absolutely identical dbg.declares and the assert in addFragmentOffset() blows.