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