Displaying 20 results from an estimated 4000 matches similar to: "[LLVMdev] Refusing to store single element"
2008 Jul 09
0
[LLVMdev] Refusing to store single element
On Wed, 9 Jul 2008, Nicolas Capens wrote:
> I'm hitting the following assert in PredicateSimplifier.cpp:961 :
Hi Nicolas,
The predsimplify pass is experimental at best, and should be removed at
worst. I don't think it is going to be futher developed, so I'd suggest
staying away from it.
-Chris
>
>
> assert(!CR.isSingleElement() && "Refusing to store
2009 Feb 16
3
[LLVMdev] PredicateSimplifier questions
PredicateSimplifier is a pretty interesting pass, but it doesn't look
like opt invokes it at any standard -Ox level, and so I assume that
llvm-gcc also does not use this pass? If that is right, I'm curious
about why this is the case -- does it simply not provide enough code
speedup to compensate for the increase in compile time?
Also, a colleague and I (we both teach advanced
2008 May 25
3
[LLVMdev] A quick update on FreeBSD support
On May 25, 2008, at 12:58 AM, Bill Wendling wrote:
> On May 24, 2008, at 4:25 PM, Marcel Moolenaar wrote:
>
>> On May 24, 2008, at 12:12 PM, Bill Wendling wrote:
>>
>>> Let us know if you would like extra eyes on the two PPC failures.
>>> Many
>>> of us have a lot of experience with C++. :-) Do you know where these
>>> allocations are?
2008 May 26
0
[LLVMdev] A quick update on FreeBSD support
On May 25, 2008, at 1:39 PM, Marcel Moolenaar wrote:
> On May 25, 2008, at 12:58 AM, Bill Wendling wrote:
>
>> Could you try this (massively hacky) patch out to see if it fixes
>> your
>> problem?
>>
>>
> Alas, it didn't fix the problem:
>
Crumbs.
I think that the analysis I told you before wasn't fully correct. I
think I mentioned something
2008 May 26
2
[LLVMdev] use after free [was: A quick update on FreeBSD support]
On May 26, 2008, at 1:25 AM, Bill Wendling wrote:
> On May 25, 2008, at 1:39 PM, Marcel Moolenaar wrote:
>> On May 25, 2008, at 12:58 AM, Bill Wendling wrote:
>>
>>> Could you try this (massively hacky) patch out to see if it fixes
>>> your
>>> problem?
>>>
>>>
>> Alas, it didn't fix the problem:
>>
> Crumbs.
>
>
2008 May 24
5
[LLVMdev] A quick update on FreeBSD support
On May 24, 2008, at 12:12 PM, Bill Wendling wrote:
> Let us know if you would like extra eyes on the two PPC failures. Many
> of us have a lot of experience with C++. :-) Do you know where these
> allocations are?
I don't mind if people help out, so here's some information:
FAIL: /nfs/llvm/src/llvm/test/Transforms/PredicateSimplifier/
2006-11-04-ReplacingZeros.ll
Failed with
2008 May 25
0
[LLVMdev] A quick update on FreeBSD support
On May 24, 2008, at 4:25 PM, Marcel Moolenaar wrote:
> On May 24, 2008, at 12:12 PM, Bill Wendling wrote:
>
>> Let us know if you would like extra eyes on the two PPC failures.
>> Many
>> of us have a lot of experience with C++. :-) Do you know where these
>> allocations are?
>
> I don't mind if people help out, so here's some information:
>
Could
2009 Feb 16
0
[LLVMdev] PredicateSimplifier questions
Hi John,
John Regehr wrote:
> PredicateSimplifier is a pretty interesting pass, but it doesn't look
> like opt invokes it at any standard -Ox level, and so I assume that
> llvm-gcc also does not use this pass? If that is right, I'm curious
> about why this is the case -- does it simply not provide enough code
> speedup to compensate for the increase in compile time?
I
2008 May 24
0
[LLVMdev] A quick update on FreeBSD support
On May 24, 2008, at 11:43 AM, Marcel Moolenaar wrote:
> All,
>
> So far I've tried LLVM on amd64, i386, ia64 and powerpc under FreeBSD
> and aside for ia64, things look pretty good for a first try. There
> are 2 unexpected failures for PowerPC, which appear to be caused by
> uninitialized memory. I'm still working on a fix for that (need to
> brush up on my C++
2008 May 24
2
[LLVMdev] A quick update on FreeBSD support
All,
So far I've tried LLVM on amd64, i386, ia64 and powerpc under FreeBSD
and aside for ia64, things look pretty good for a first try. There
are 2 unexpected failures for PowerPC, which appear to be caused by
uninitialized memory. I'm still working on a fix for that (need to
brush up on my C++ skills).
[sidenote: In FreeBSD -current, the memory allocator initializes
memory with 0xa5
2007 Aug 06
2
[LLVMdev] Problem compiling LLVM under Cygwin/Mingw
Hello,
I'm starting to play with LLVM today and I've trouble compiling it. I'm
working under Windows Vista, with the gcc from Cygwin:
gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
Is LLVM supposed to work with this version of GCC (probably using the
-mno-cygwin option to get a Mingw-like behavior)?
The LLVM source tree is from the current SVN trunk.
Compilation
2007 Aug 06
1
[LLVMdev] Problem compiling LLVM under Cygwin/Mingw
Hello, Alain.
> I'm starting to play with LLVM today and I've trouble compiling it.
> I'm
> working under Windows Vista, with the gcc from Cygwin:
Oh, this seems to be killer mix :) GCC (at least native mingw32 port)
has known problems being running on Vista.
> Is LLVM supposed to work with this version of GCC (probably using the
> -mno-cygwin option to get a
2009 Feb 16
3
[LLVMdev] PredicateSimplifier questions
> Predsimplify is believed to have bugs (it results in miscompiled
> programs) and certainly isn't efficient (it was written before much of
> include/ADT). Finally, predsimplify is likely to go away once I or
> someone else writes a proper VRP pass.
Whoever does this, I strongly encourage looking into using (or at least
providing optional support for) the Apron library:
2007 Jul 27
2
[LLVMdev] Couple of changes (2005 and other toolchain related)
Hi,
I upgraded the Visual Studio SLN file to work with 2005 and had to make some
changes.
The first two have to do with the fact that the debug implementation of 2005's
STL does all sort of validation, that's why they didnt show up on 2003.
I'm not set up for patch submission yet, but if somebody has time to review
these changes that'd be greatly appreciated.
Meanwhile
2009 Feb 16
0
[LLVMdev] PredicateSimplifier questions
On Feb 15, 2009, at 10:08 PM, John Regehr wrote:
>> Predsimplify is believed to have bugs (it results in miscompiled
>> programs) and certainly isn't efficient (it was written before much
>> of
>> include/ADT). Finally, predsimplify is likely to go away once I or
>> someone else writes a proper VRP pass.
>
> Whoever does this, I strongly encourage looking
2008 May 26
0
[LLVMdev] use after free [was: A quick update on FreeBSD support]
Thanks for tracking this down! I can't seem to reproduce it on Linux,
even with valgrind.
Can you try out this patch and let me know whether it works?
Nick
Marcel Moolenaar wrote:
> On May 26, 2008, at 1:25 AM, Bill Wendling wrote:
>
>> On May 25, 2008, at 1:39 PM, Marcel Moolenaar wrote:
>>> On May 25, 2008, at 12:58 AM, Bill Wendling wrote:
>>>
2007 Mar 31
0
[LLVMdev] May 25th 2007 Developers Meeting (Update)
Reid Spencer wrote:
If you haven't confirmed your attendance yet, please do so by
> responding to this email.
I'll be there.
Furthermore, I'd like to present the Design and Implementation of the
PredicateSimplifier pass, or, "VRP in LLVM".
Nick Lewycky
2007 Aug 06
0
[LLVMdev] Problem compiling LLVM under Cygwin/Mingw
In any case, it seems that GCC 3.4.4 may be in hot water even if you
did get it to compile:
http://llvm.org/docs/GettingStarted.html#brokengcc
--
Christopher Lamb
On Aug 6, 2007, at 9:48 AM, Alain Frisch wrote:
> Hello,
>
> I'm starting to play with LLVM today and I've trouble compiling it.
> I'm
> working under Windows Vista, with the gcc from Cygwin:
>
>
2007 May 31
4
[LLVMdev] Advice on a VStudio specific patch
Here are the two problem areas:
RegisterInfoEmitter.cpp
// Emit the subregister + index mapping function based on the
information
// calculated above.
OS << "unsigned " << ClassName
<< "::getSubReg(unsigned RegNo, unsigned Index) const {\n"
<< " switch (RegNo) {\n"
<< " default: abort(); break;\n";
...
2015 Jan 15
2
[LLVMdev] generate llvm.assume calls in GVN?
On 15 January 2015 at 10:49, Chandler Carruth <chandlerc at google.com> wrote:
> On Thu, Jan 15, 2015 at 10:30 AM, Sanjay Patel <spatel at rotateright.com>
> wrote:
>
>> Would it be wrong to generate the llvm.assume IR suggested below? in GVN?
>>
>
> I think so... Because:
>
> One very small tweak you could make would be to add an llvm.assume inside