Displaying 20 results from an estimated 1000 matches similar to: "[LLVMdev] Patch to get llvm compiling with the Intel 11.0.066 compiler"
2010 Sep 01
3
[LLVMdev] Assertion failure in tablegen: rationale ?
Hello,
I was fiddling with TableGen (for a use that has nothing to do with a
compiler but it's doesn't matter) and TableGen triggers an assertion failure
on this code (I reduced the case to the minimum, it's a parsing bug):
class Bli<string _t>
{
string t = _t;
}
class Bla<list<Bli> _bli>
: Bli<!car(_bli).t>
{
}
#0 0x00007ffff6ebda75 in *__GI_raise
2010 Sep 01
0
[LLVMdev] Assertion failure in tablegen: rationale ?
On Sep 1, 2010, at 4:35 AM, Amaury Pouly wrote:
> Hello,
> I was fiddling with TableGen (for a use that has nothing to do with a compiler but it's doesn't matter) and TableGen triggers an assertion failure on this code (I reduced the case to the minimum, it's a parsing bug):
David, can you take a look? This is related to your lisp interpreter :)
-Chris
>
> class
2008 Nov 13
0
[LLVMdev] 'struct' now seen using 'class'
Hi,
I'm new to Clang / LLVM, and trying to build so that it will run
natively on Windows.
Used the CMake approach (thanks to whoever created the configs for
this). Had to comment out "DbgInfoRemover.cpp" in one of the make files
(didn't spend time to figure out why), following which CMake produced a
nice working Visual Studio 2008 solution file. I opened this up in VS
2010 Sep 01
1
[LLVMdev] Assertion failure in tablegen: rationale ?
While I'm at it, I noticed a behaviour which is not exactly related but
similar. To put it simply, you can 't do T.V.W, you need to do
!cast<Bla>(T.V).W
Example:
class Bla<string t>
{
string blu = t;
}
class Bli<Bla t>
{
Bla bla = t;
}
def a : Bli<Bla<"">>;
def b : Bla<!cast<Bla>(a.bla).blu>; // works
def b :
2008 Oct 13
0
[LLVMdev] aborting on invalid code
On Oct 13, 2008, at 1:10 PM, Robert Zeh wrote:
>
> On Oct 13, 2008, at 1:07 PM, Chris Lattner wrote:
>>
>> Exceptions have a high cost in terms of code size, binary size, and
>> even a bit of execution time. Also, they don't magically make the
>> code safe from any error: code has to be designed specifically to use
>> RAII and other techniques to handle
2012 Jan 20
1
[LLVMdev] TableGen Crash
Hi LLVMers,
I found a bug in TGParser that is causing llvm-tblgen to crash on bad
input. The reduced testcase is attached. The output follows:
$ ./llvm-tblgen --version
Low Level Virtual Machine (http://llvm.org/):
LLVM version 3.1svn
DEBUG build with assertions.
Built Jan 20 2012 (15:46:08).
Default target: x86_64-apple-darwin11.2.0
Host CPU: penryn
$ ./llvm-tblgen bug.td
0
2014 Sep 25
5
[LLVMdev] New type of smart pointer for LLVM
Hello everyone,
I bring to discussion the necessity/design of a new type of smart
pointer. r215176 and r217791 rise the problem, D5443
<http://reviews.llvm.org/D5443> is devoted to the solution.
r215176 applies several temporary ugly fixes of memory leaks in
TGParser.cpp which would be great to be refactored using smart pointers.
D5443 <http://reviews.llvm.org/D5443> demonstrates
2014 Oct 01
4
[LLVMdev] New type of smart pointer for LLVM
On Wed, Oct 1, 2014 at 3:14 PM, Anton Yartsev <anton.yartsev at gmail.com>
wrote:
> Ping!
>
> Suggested is a wrapper over a raw pointer that is intended for freeing
> wrapped memory at the end of wrappers lifetime if ownership of a raw
> pointer was not taken away during the lifetime of the wrapper.
> The main difference from unique_ptr is an ability to access the wrapped
2008 Oct 13
2
[LLVMdev] aborting on invalid code
On Oct 13, 2008, at 1:07 PM, Chris Lattner wrote:
>
> Exceptions have a high cost in terms of code size, binary size, and
> even a bit of execution time. Also, they don't magically make the
> code safe from any error: code has to be designed specifically to use
> RAII and other techniques to handle exceptions properly. Reading a C+
> + trade magazines/books about EH topics
2012 Jul 03
0
[LLVMdev] tablegen multiple inheritance question
Seems to just be a byproduct of TGParser::AddSubClass() begin called
twice. This means that TGParser::AddValue() is being called once for
the "i" of each class, and the "last one wins".
Not sure if it is intended, but this behavior seems to more-or-less
"make sense".
--Sean Silva
On Mon, Jul 2, 2012 at 4:55 PM, reed kotler <rkotler at mips.com> wrote:
>
2017 Apr 15
2
About TableGen RangeList
Hi All,
One thing I believe also bothers someone else. Say we have the following
code snippet:
bits<32> insnEncoding;
let insnEncoding{15-12} = 0b0100;
Can we write the let expression with range list like this, with the same
meaning?
let insnEncoding{12-15} = 0b0100;
I take a look on TGParser::ParseRangePiece (lib/TableGen/TGParser.cpp),
seems the
answer is YES. Can anyone
2010 Dec 10
1
[LLVMdev] tblgen internals
Attached patch for removing for the first trivial RecordKeeper:: getAllDerivedDefinitions(...)
dependency on the global RecordKeeper Records instance. The real work will be removing
this dependency from the other Record.h classes/structs, and from TGParser. Thinking this would
be implemented as some sort of context structure/class holding a RecordKeeper instance passed
to TGParser which in turn
2009 Aug 28
0
[LLVMdev] andersen's alias analysis
Might I suggest the following patch, because this issue has bite me
too? You're lured in by the initial good results from the Andersens
alias analysis, only to discover the bugs later on.
Robert Zeh
On Aug 26, 2009, at 9:11 PM, Chris Lattner wrote:
> On Aug 26, 2009, at 6:40 PM, Max Stonebraker wrote:
>> Hello,
>>
>> Does the LLVM Andersens alias analysis handle
2008 Feb 13
5
[LLVMdev] Instrumenting virtual function calls
After hacking away at it for a bit, it looks like the mystery function
is actually a stub function. The function pointer is coming from a
vtable, which gets filled in with pointers to stub functions.
Is there any way to do the round trip for a stub function? Two
possible solutions come to mind:
1) Modify getGlobalValueAtAddress to work for pointers to stub
functions
2) Add a
2012 Oct 05
1
[LLVMdev] TableGen: Requesting feedback for "TGContext"
>> Ok, here's the first batch. It converts the RecTy hierarchy over to
>> use LLVM-style RTTI. Along the way, I also wrote up a new doc "How to
>> set up LLVM-style RTTI for your class hierarchy", which covers the
>> previously undocumented (albeit not that complicated) process for
>> hooking into Support/Casting.h.
>
> Cool. Please pull this
2012 Oct 05
0
[LLVMdev] TableGen: Requesting feedback for "TGContext"
On Oct 4, 2012, at 5:15 PM, Sean Silva <silvas at purdue.edu> wrote:
>> It won't cause a negative effect, go for it! Dynamic_cast is realllly slow compared to dyn_cast, it is worth the memory.
>
> Ok, here's the first batch. It converts the RecTy hierarchy over to
> use LLVM-style RTTI. Along the way, I also wrote up a new doc "How to
> set up LLVM-style
2011 Oct 07
0
[LLVMdev] Enhancing TableGen
My purpose is to eliminate copy-paste style of programming in td files
as much as possible, but only to a point that the new language
constructs do not create too much overhead/readability-downgrade.
In other words, I am targeting those low-hanging fruit of copy-paste
programmings in td files that are eliminated by a simple for-loop
syntax. The repetitive patterns I observed in PTX backend (and
2008 Feb 13
0
[LLVMdev] Instrumenting virtual function calls
On Feb 12, 2008, at 5:08 PM, Robert Zeh wrote:
> After hacking away at it for a bit, it looks like the mystery
> function is actually a stub function.
You know, I had this lengthy email written to cover all the details
and I decided not to send it as I wasn't sure if that was what you
were hitting a stub and I didn't want to confuse the issue if it
wasn't due to stubs...
2012 Oct 05
2
[LLVMdev] TableGen: Requesting feedback for "TGContext"
> It won't cause a negative effect, go for it! Dynamic_cast is realllly slow compared to dyn_cast, it is worth the memory.
Ok, here's the first batch. It converts the RecTy hierarchy over to
use LLVM-style RTTI. Along the way, I also wrote up a new doc "How to
set up LLVM-style RTTI for your class hierarchy", which covers the
previously undocumented (albeit not that
2013 Jan 31
2
[LLVMdev] std::string suffices for Init* argument?
Hi Jakob,
How is `FieldName`, which is a std::string, being passed as the third
argument to SetValue on line 1848 of TGParser.cpp, which is declared
as being an Init*? The nearly identical (FIXME) codepath in
ParseDeclaration immediately puts the string into a StringInit, which
makes sense, but how on earth is the std::string being passed in? This
is really freaking me out.
-- Sean Silva