Displaying 20 results from an estimated 10000 matches similar to: "[LLVMdev] non-signed integer Type"
2008 Oct 27
2
[LLVMdev] maintaining names for types
Hi
I'm working on switching from generating textual .ll files in my front
end to using the llvm-c IR builder API instead.
One thing that I really miss is that when I dump() to a .ll file for
debugging, the type names are worse than useless, because many types
have been merged with unrelated types that happen to have the same
shape. This becomes very confusing when trying to map back to the
2008 Oct 29
0
[LLVMdev] maintaining names for types
I run into this problem as well. However, given the way LLVM represents
types and their names, there is not an easy solution to this problem. I
don't know of any real workaround that will not change the semantics of the
code.
- Daniel
On Mon, Oct 27, 2008 at 4:42 PM, Scott Graham <scott.llvm at h4ck3r.net> wrote:
> Hi
>
> I'm working on switching from generating textual
2008 Jul 23
2
[LLVMdev] customized output of double load/store on ppc32
Hi
For .LL like:
define void @Func()
{
%var1 = alloca double
store double 0x40bb580000000000, double* %var1
ret void
}
ppc32 output is:
...
lis 3, 16571
ori 3, 3, 22528
li 4, 0
stw 3, 8(1)
stw 4, 12(1)
...
I'm using the PPC backend's output as the "bytecode" for an interpreter
that I would like to be able to run
2008 Jul 24
2
[LLVMdev] customized output of double load/store on ppc32
On Wed, Jul 23, 2008 at 4:46 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
> On Wed, Jul 23, 2008 at 4:23 PM, Scott Graham <scott.llvm at h4ck3r.net> wrote:
>> I'm using the PPC backend's output as the "bytecode" for an interpreter
>> that I would like to be able to run on both little- and big-endian
>> platforms. The split stw's mean
2008 Aug 12
4
[LLVMdev] CLR or C++/CLI interface to IR building API
Hi
Our front end is written in a CLR language, and we're currently
interacting with the middle/back-end by writing out .ll files. This
was convenient to get started with, but they're getting to a "huge and
unwieldy" stage now.
I was wondering if anyone's attempted writing proxy/wrapper C++/CLI
classes so that the IR API can be used directly from managed
languages. Any
2008 Sep 08
3
[LLVMdev] Problems when refining type
Hi
I'm using the llvm-c wrapper, and trying to build some recursive types
(using released 2.3).
I get an assert on trying to create a second opaque pointer type after
refining a first.
The first time through creating an opaque pointer type, a new type is
created and returned from PointerType::get, but the second time,
ValueType (the opaque type) is found in the PointerTypes map, which
seems
2008 Oct 29
2
[LLVMdev] maintaining names for types
Shucks, I figured as much, but I was hoping...
Relatedly, it would be convenient to have a way to reliably influence
which name gets chosen for the merged type. If I could at least have
things like "%ObjHeader" not turn into
"%SomeUserCodeType_NestedUserClass_Blorp", that would go a long way.
scott
On Tue, Oct 28, 2008 at 9:16 PM, Daniel Dunbar <daniel at zuster.org>
2004 Aug 21
3
[LLVMdev] More Encoding Ideas
On Fri, 20 Aug 2004, Reid Spencer wrote:
> > defined would be almost always stored in one byte instead of the present
> > usual two.
>
> So, if I get you correctly, you're advocating the creation of a Type::CharTyID
> in the TypeID enumeration that is always written as a single byte? Note that
> right now all ASCII values ( <128 ) will be written as a single byte for
2008 Jul 23
0
[LLVMdev] customized output of double load/store on ppc32
On Wed, Jul 23, 2008 at 4:23 PM, Scott Graham <scott.llvm at h4ck3r.net> wrote:
> I'm using the PPC backend's output as the "bytecode" for an interpreter
> that I would like to be able to run on both little- and big-endian
> platforms. The split stw's mean that i32s of the f64 are swapped in
> memory on little-endian (thus foiling native-code interop).
2008 Aug 13
0
[LLVMdev] CLR or C++/CLI interface to IR building API
Take a look at this page. It might give you more information:
http://vmkit.llvm.org/
-bw
On Tue, Aug 12, 2008 at 4:38 PM, Scott Graham <scott.llvm at h4ck3r.net> wrote:
> Hi
>
> Our front end is written in a CLR language, and we're currently
> interacting with the middle/back-end by writing out .ll files. This
> was convenient to get started with, but they're
2007 Jun 24
2
[LLVMdev] alloca on Win32
Hi
When using lli on Win32 (vs.net-built), on any non-trivial code, I get the
following abort
ERROR: Program used external function '_alloca' which could not be resolved!
Checking the assembly from llc, the first alloca call is to allocate local
vars in _main. Is this just the state of the code at 2.0 when built with
vs.net, or is there something that I've managed to mis-build
2008 Sep 29
2
[LLVMdev] Integer handling
I have ended up making a rather complicated type system to handle
quite a few things, all stemming from the fact that the integer type
has no sign information (even if it did not use it, would be nice to
look at it in my code generator to so I can put out one function type
or another when something like udiv/sdiv is called). I essentially
have a variant that holds either an llvm::Type* (which at
2004 Aug 21
0
[LLVMdev] More Encoding Ideas
At 05:09 PM 8/20/2004, you wrote:
>On Fri, 20 Aug 2004, Reid Spencer wrote:
> > > defined would be almost always stored in one byte instead of the present
> > > usual two.
> >
> > So, if I get you correctly, you're advocating the creation of a
> Type::CharTyID
> > in the TypeID enumeration that is always written as a single byte? Note
> that
>
2008 Oct 26
0
[LLVMdev] Header files on VC project (was: Growing up CMake)
On Sat, Oct 25, 2008 at 9:09 PM, Óscar Fuentes <ofv at wanadoo.es> wrote:
> I've checked that Intellisense can jump to an unlisted header file when
> you ask for a declaration on a cpp file. So, what's the benefit of
> having the header files explicitly listed in the solution? If it is for
> text searching, maybe putting them on just one project (Hello.lib, for
>
2008 Nov 03
0
[LLVMdev] Buildbot now up and new build failures
On Sun, Nov 2, 2008 at 1:02 PM, Daniel Berlin <dberlin at dberlin.org> wrote:
> I set up a buildbot for llvm at http://google1.osuosl.org:8011/waterfall
> It builds every single revision of llvm, runs the testsuite, and
> reports the results. It takes about 3 minutes per build+test right
> now (it's an 8 core machine).
>
> Currently i have it building x86_64-linux.
2008 Nov 04
1
[LLVMdev] Inserting comments
On Tue, Nov 4, 2008 at 9:39 AM, Devang Patel <dpatel at apple.com> wrote:
>
>> Anyone have any clever way of inserting a comment (or
>> comment-ish-thing) that will make it to an .ll that's generated at the
>> same time as writing out the bitcode?
>> ...
>
> Try using llvm.var.annotation intrinsic.
Thanks for the suggestion. I'd tried doing that by
2008 Nov 10
1
[LLVMdev] MSVC Targets in CMake
Hi
Any reason why the CMake build doesn't include more target backends
under MSVC? (Currently only x86). I just tried turning on all the
backends and everything seems to build OK. I don't know if they all
run correctly.
If there isn't a good reason, attached is the trivial patch to include
all targets.
scott
-------------- next part --------------
A non-text attachment was
2008 Nov 12
1
[LLVMdev] cmake patch to build other targets
Hi, attached is a patch to improve including targets other than X86 in
CMake MSVC builds.
When adding libs to link, rather than always using LLVMX86CodeGen and
LLVMX86AsmPrinter, it grabs the correct ones.
It also adds "force-link-ints" to the various TargetMachine cpp files,
as well as X86AsmPrinter and PPCAsmPrinter. These are needed to be
able to encourage the Win32 linker to
2008 Oct 26
1
[LLVMdev] Header files on VC project (was: Growing up CMake)
Argiris Kirtzidis <akyrtzi at gmail.com> writes:
> Óscar Fuentes wrote:
>> All the headers in include/llvm? Or just those local to each library?
>>
>
> All the headers. It's a pain to manually update the project files but it
> will be a bigger pain trying to use them without the include files..
> included.
There are almost 300 headers under include/llvm.
2007 Nov 06
4
[LLVMdev] Passing and returning aggregates (who is responsible for the ABI?)
Hello,
I'm trying to port the XL compiler (http://xlr.sf.net) to use the
LLVM back-end. So far, little trouble doing so. But there is one
aspect of the semantics of the LLVM IR that surprises me. Why are the
call, declare and define "halfway through" ABI conventions?
I think it's the right thing to have a single high level node for
each call, as opposed to separate