similar to: [LLVMdev] llvm-ld -On ?

On Jan 9, 2009, at 8:22 AM, Jay Foad wrote: > It appears that in LLVM 2.4, llvm-ld no longer accepts -On options to > control optimisation. LLVM 2.3 and previously accepted and ignored them, llvm-ld now rejects them. A lot of the llvm-ld man page were theoretical features that were never implemented unfortunately. > 1. This isn't mentioned in the 2.4 release notes. Sorry.

On Fri, Apr 1, 2011 at 1:58 AM, Jay Foad <jay.foad at gmail.com> wrote: > On 30 March 2011 19:08, Talin <viridia at gmail.com> wrote: > > llvm.gc.declare(alloca, meta). This intrinsic marks an alloca as a > garbage > > collection root. It can occur anywhere within a function, and lasts > either > > until the end of the function, or a until matching call to

Hi, I noticed this code in lib/Transforms/Scalar/InstructionCombining.cpp: cerr << "WARNING: While resolving call to function '" << Callee->getName() << "' arguments were dropped!\n"; If you're using LLVM as a static compiler, this warning is a bit incongruous, because it's not formatted in the same way as warnings from

On Fri, Apr 1, 2011 at 2:17 PM, Jay Foad <jay.foad at gmail.com> wrote: > This is very similar to the problem of representing lexical scopes in > debug info. The llvm.dbg.region.* intrinsics were the wrong way of > doing it, because of the problems I mentioned above. Now we use > metadata attached  to each instruction to say what scope it is in, > which is much better, because

>> if (cond) { >>  llvm.gc.declare(foo, bar); >> } >> ... >> // foo may or may not be a root here >> ... >> if (cond) { // same condition as above >>  llvm.gc.undeclare(foo); >> } >> > You would need to do the same as what is done today: Move the declare > outside of the condition, and initialize the variable to a null state, such

On Feb 27, 2009, at 1:47 AM, Jay Foad wrote: > Hi, > > I noticed this code in lib/Transforms/Scalar/InstructionCombining.cpp: > > cerr << "WARNING: While resolving call to function '" > << Callee->getName() << "' arguments were dropped!\n"; > > If you're using LLVM as a static compiler, this warning is a

On 30 March 2011 19:08, Talin <viridia at gmail.com> wrote: > llvm.gc.declare(alloca, meta). This intrinsic marks an alloca as a garbage > collection root. It can occur anywhere within a function, and lasts either > until the end of the function, or a until matching call to > llvm.gc.undeclare(). > llvm.gc.undeclare(alloca). This intrinsic unmarks and alloca, so that it is

On 6 August 2011 23:05, Jason Kim <jasonwkim at google.com> wrote: > Hi everyone, > -r136747 of llvm-gcc (and possibly others) is apparently tickling a binutils > issue on linux x86-64 > Has anyone seen anything like this? Yes, it looks like this: http://sourceware.org/bugzilla/show_bug.cgi?id=12887 I think switching from ld to gold might be an effective work-around. Jay.

I see that llvm-gcc now has some support for generating debug info when optimising - thanks! However, it still doesn't generate debug info for global variables when optimising. Is there any reason for this? With the attached patch, the whole test suite passes for me with TEST=ipodbgopt. Thanks, Jay. -------------- next part -------------- A non-text attachment was scrubbed... Name:

Hi, I've just tried to run the test-suite, for the first time in ages. It stops rather abruptly with: $ make TEST=nightly report report.html /home/jay/llvm/local/bin/llvm-gcc -I/home/jay/llvm/gitobjdir/projects/test-suite/SingleSource/UnitTests -I/home/jay/svn/llvm-project/test-suite/trunk/SingleSource/UnitTests -I/home/jay/git/llvm/projects/test-suite/include -I../../include

Hi, Various parts of LLVM seem to assume that the ABI for a varargs function is compatible with the ABI for a non-varargs function, so that code like this: define void @f(i32 %x) { ... } ... call void (...)* bitcast (void (i32)* @f to void (...)*)(i32 42) will work. (I don't think C guarantees that this will work, at least not in the version of the C99 standard I checked.) I'm

On 6 May 2011 09:29, Jay Foad <jay.foad at gmail.com> wrote: > I've just tried to run the test-suite, for the first time in ages. It > stops rather abruptly with: > > $ make TEST=nightly report report.html > > /home/jay/llvm/local/bin/llvm-gcc > -I/home/jay/llvm/gitobjdir/projects/test-suite/SingleSource/UnitTests >

In LowerGET_DYNAMIC_AREA_OFFSET() you're calling MFI->getMaxCallFrameSize(), but it looks like that doesn't return useful information until after the PrologEpilogInserter's PEI::calculateCallsInformation() has run. So maybe the lowering has to be done as part of frame index elimination? (I'm not too familiar with this code.) Jay. On 23 November 2015 at 13:07, Jay Foad

On Nov 8, 2011, at 7:18 AM, Jay Foad wrote: > On 7 November 2011 22:00, Bill Wendling <wendling at apple.com> wrote: >> We are starting on our third (and hopefully last) round of testing for LLVM 3.0. Please visit: >> >> http://llvm.org/pre-releases/3.0/rc3/ >> >> for the sources. There are also binaries for Darwin up there, with more to come during

Hi Jay, they all seem to work with dragonegg, so I closed them. Ciao, Duncan. On 04/05/12 13:37, Jay Foad wrote: > On 1 May 2012 12:34, Jay Foad<jay.foad at gmail.com> wrote: >> The following bugs look like they only relate to llvm-gcc. Can they be >> closed, as llvm-gcc is no longer supported? > > Also: > > http://llvm.org/bugs/show_bug.cgi?id=1375 >

On 13 February 2012 09:22, Jay Foad <jay.foad at gmail.com> wrote: > Would it be possible to use CityHash instead for strings? > > http://code.google.com/p/cityhash/ Incidentally there was talk of using CityHash for LLVM's StringMap last year, but I don't think it ever came to anything: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-April/014656.html Jay.

On 11 November 2010 12:49, Jay Foad <jay.foad at gmail.com> wrote: > Delving a bit deeper, the difference seems to be that symbol "i" in > the assembler source: > >        .type   i, at object               # @i >        .section        .tdata,"awT", at progbits >        .globl  i >        .align  4 > i: >        .long   7                      

On 13 May 2014 21:27, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > On 13 May 2014 14:33, Jay Foad <jay.foad at gmail.com> wrote: >> I've always found the name ComputeMaskedBits a bit unintuitive, and >> since r154011 it's even worse because there is no masking going on >> whatsoever: >> >>

Hi, I'd like to use LLVM to compile and optimise code when I don't know whether the target CPU is big- or little-endian. This would allow me to create a single optimised LLVM bitcode binary of an application, and then run it through a JIT compiler on systems of differening endianness. I realise that in general the LLVM IR depends on various characteristics of the target; I'd just

How about tweaking the compiler-rt cmakefiles so that if lsan is not supported, the target check-lsan still exists but does nothing? I've attached a patch that does this. (I don't know much about cmake so there might be a better way of doing it.) Alternatively, can I change the zorg build script so that "run sanitizer tests in gcc build" doesn't try to run check-lsan etc