similar to: [LLVMdev] Target data question

Displaying 20 results from an estimated 20000 matches similar to: "[LLVMdev] Target data question"

2009 Oct 20
0
[LLVMdev] Target data question
On Oct 20, 2009, at 9:26 AM, Kenneth Uildriks wrote: > According to the "LLVM Assembly Language Reference Manual": > > When constructing the data layout for a given target, LLVM starts with > a default set of specifications which are then (possibly) overriden by > the specifications in the datalayout keyword. The default > specifications are given in this list: >
2009 Oct 20
4
[LLVMdev] Target data question
On Tue, Oct 20, 2009 at 12:08 PM, Dan Gohman <gohman at apple.com> wrote: > Unfortunately, yes.  See PR4542.  Progress has been made recently > though -- the optimizers are now ready.  The main things left to do > is to update the documentation and update the testsuite to account > for the change in the meaning of a module without a targetdata string. > > Dan > > So
2009 Oct 20
0
[LLVMdev] Target data question
On Tue, Oct 20, 2009 at 12:13 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote: > On Tue, Oct 20, 2009 at 12:08 PM, Dan Gohman <gohman at apple.com> wrote: >> Unfortunately, yes.  See PR4542.  Progress has been made recently >> though -- the optimizers are now ready.  The main things left to do >> is to update the documentation and update the testsuite to
2009 Oct 20
0
[LLVMdev] Target data question
On Oct 20, 2009, at 10:13 AM, Kenneth Uildriks wrote: > On Tue, Oct 20, 2009 at 12:08 PM, Dan Gohman <gohman at apple.com> wrote: >> Unfortunately, yes. See PR4542. Progress has been made recently >> though -- the optimizers are now ready. The main things left to do >> is to update the documentation and update the testsuite to account >> for the change in the
2009 Oct 21
2
[LLVMdev] Target data question
On Tue, Oct 20, 2009 at 12:50 PM, Dan Gohman <gohman at apple.com> wrote: > > On Oct 20, 2009, at 10:13 AM, Kenneth Uildriks wrote: > >> On Tue, Oct 20, 2009 at 12:08 PM, Dan Gohman <gohman at apple.com> wrote: >>> Unfortunately, yes.  See PR4542.  Progress has been made recently >>> though -- the optimizers are now ready.  The main things left to do
2009 Oct 21
2
[LLVMdev] Target data question
>> Anyway, my present plan of attack is to have a "-defaulttarget" option >> with "none", "host", or a target string.  If -defaulttarget is not >> specified, the behavior of "opt" will be the same as it is presently. >> The defaulttarget will be overridden by the Module's target data if it >> has some.  "none"
2009 Oct 22
0
[LLVMdev] Target data question
On Wed, Oct 21, 2009 at 4:47 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote: >> I think it's more intuitive to have command-line information override >> Module information. That's how llc works, for example. >> >> Also, is the argument to -defaulttarget a triple, an architecture name, >> or a targetdata string? If it's a triple, it'd be
2009 Oct 21
2
[LLVMdev] Target data question
On Wed, Oct 21, 2009 at 10:59 AM, Kenneth Uildriks <kennethuil at gmail.com> wrote: > If the TargetData pass isn't registered in the global registry, > getPassInfo() returns null. > > Now when you add a TargetData pass, it winds up in ImmutablePasses. > Any search through ImmutablePasses assumes that getPassInfo() for > every member returns something other than null.
2009 Oct 21
0
[LLVMdev] Target data question
If the TargetData pass isn't registered in the global registry, getPassInfo() returns null. Now when you add a TargetData pass, it winds up in ImmutablePasses. Any search through ImmutablePasses assumes that getPassInfo() for every member returns something other than null. So findAnalysisPass for *any* analysis pass can crash the system if the TargetData pass is lurking in the list without
2009 Oct 22
3
[LLVMdev] Target data question
On Oct 22, 2009, at 7:25 AM, Kenneth Uildriks wrote: > On Wed, Oct 21, 2009 at 4:47 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote: >>> I think it's more intuitive to have command-line information override >>> Module information. That's how llc works, for example. >>> >>> Also, is the argument to -defaulttarget a triple, an architecture
2009 Sep 06
2
[LLVMdev] loads from a null address and optimizations
On Sun, Sep 6, 2009 at 3:19 PM, Kenneth Uildriks<kennethuil at gmail.com> wrote: > It would be unfortunate in a way if "this instruction can trap and go > there" is taken to mean "if this instruction has no effect other than > a possible trap, the instruction and the trapping behavior *must* be > preserved". What exactly would the semantics be if the
2009 Oct 21
0
[LLVMdev] Target data question
On Oct 21, 2009, at 9:31 AM, Kenneth Uildriks wrote: > On Wed, Oct 21, 2009 at 10:59 AM, Kenneth Uildriks <kennethuil at gmail.com> wrote: >> If the TargetData pass isn't registered in the global registry, >> getPassInfo() returns null. >> >> Now when you add a TargetData pass, it winds up in ImmutablePasses. >> Any search through ImmutablePasses
2010 Oct 24
2
[LLVMdev] lli : external functions and target datalayout
Hi All, I have a C code: ////////////////////////////// #include "stdio.h" int main () { putchar('a'); return 0; } llvm-gcc -emit-llvm, I got //////////////////////////////////////// ; ModuleID = 't1.bc' target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32" target triple
2010 Oct 24
0
[LLVMdev] lli : external functions and target datalayout
Jianzhou Zhao <jianzhou at seas.upenn.edu> writes: [snip] > The other question is about > target datalayout = > "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32" > > If I use this string to creat a TargetData object directly, I got an > assertion error: > >
2009 Nov 09
5
[LLVMdev] Proposal: intp type
Simply put, it's a pointer-sized integer. I'm blatantly stealing this idea from .NET, where IntPtr (a pointer-sized integer) is a basic type. In my front end, I had considered just using a pointer for intp behind-the-scenes and doing conversion to/from int64 when I wanted to do arithmetic on them, but pointers and integers don't always align the same way. So what I really want is a
2010 Nov 14
2
[LLVMdev] noalias locals
On Sun, Nov 14, 2010 at 11:45 AM, Reid Kleckner <reid.kleckner at gmail.com> wrote: > On Sun, Nov 14, 2010 at 11:17 AM, Kenneth Uildriks <kennethuil at gmail.com> wrote: >> To fix that and compile C++ correctly while aggressively >> devirtualizing it, we would need to apply "noalias" to the result of >> placement-new in all cases, even when placement-new
2009 Sep 06
0
[LLVMdev] loads from a null address and optimizations
On Sun, Sep 6, 2009 at 5:32 PM, Eli Friedman<eli.friedman at gmail.com> wrote: > On Sun, Sep 6, 2009 at 3:19 PM, Kenneth Uildriks<kennethuil at gmail.com> wrote: >> It would be unfortunate in a way if "this instruction can trap and go >> there" is taken to mean "if this instruction has no effect other than >> a possible trap, the instruction and the
2009 Sep 06
3
[LLVMdev] loads from a null address and optimizations
On Sun, Sep 6, 2009 at 3:53 PM, Kenneth Uildriks<kennethuil at gmail.com> wrote: > On Sun, Sep 6, 2009 at 5:32 PM, Eli Friedman<eli.friedman at gmail.com> wrote: >> On Sun, Sep 6, 2009 at 3:19 PM, Kenneth Uildriks<kennethuil at gmail.com> wrote: >>> It would be unfortunate in a way if "this instruction can trap and go >>> there" is taken to
2012 Sep 08
3
[LLVMdev] Create target with alternate syntax for globals?
I'm working on building a target for llvm that's the intermediate language of another compiler, so that the other compiler can benifit from llvm's optimization passes. I essentially made a copy of the mips backend, and then started changing the output to match the intermediate language of the compiler. Most of the output can be overriden, but I haven't figured out how to change
2009 Aug 29
4
[LLVMdev] A create-distinct-item function with no (other) side effects
On Fri, Aug 28, 2009 at 3:47 PM, Nick Lewycky<nlewycky at google.com> wrote: > > > 2009/8/28 Kenneth Uildriks <kennethuil at gmail.com> >> >> This is by design, of course, (CreateDistinctItem does not return the >> same value given the same caller-visible global state) but I see no >> way to declare a function that: >> >> 1. Returns a