Displaying 5 results from an estimated 5 matches for "loadg".
Did you mean:
load
2013 Aug 08
0
[LLVMdev] Address space extension
...casts between different address spaces and require an explicit address space cast. To illustrate the problem, consider the following trivial example:
typedef __attribute__((address_space(256))) int* gsptr;
int *toglobal(gsptr foo)
{
return (int*)foo;
}
int load(int *foo)
{
return *foo;
}
int loadgs(gsptr foo)
{
return *foo;
}
int loadgs2(gsptr foo)
{
return *toglobal(foo);
}
When we compile this to LLVM IR with clang (disabling asynchronous unwind tables for clarity), at -O2 we get this:
define i32* @toglobal(i32 addrspace(256)* %foo) nounwind readnone ssp {
%1 = bitcast i32 addrspace...
2013 Aug 08
4
[LLVMdev] Address space extension
On Aug 7, 2013, at 7:23 PM, Michele Scandale <michele.scandale at gmail.com> wrote:
> On 08/08/2013 03:52 AM, Pete Cooper wrote:
>>> Why a backend should be responsible (meaning have knowledge) for a
>>> mapping between high level address spaces and low level address spaces?
>> Thats true. I’m thinking entirely from the persecutive of the backend
>> doing
2013 Aug 08
2
[LLVMdev] Address space extension
...ress space cast. To illustrate the problem, consider the following trivial example:
>
> typedef __attribute__((address_space(256))) int* gsptr;
>
> int *toglobal(gsptr foo)
> {
> return (int*)foo;
> }
>
> int load(int *foo)
> {
> return *foo;
> }
>
> int loadgs(gsptr foo)
> {
> return *foo;
> }
>
> int loadgs2(gsptr foo)
> {
> return *toglobal(foo);
> }
>
> When we compile this to LLVM IR with clang (disabling asynchronous unwind tables for clarity), at -O2 we get this:
>
> define i32* @toglobal(i32 addrspace(256)* %...
2013 Aug 08
0
[LLVMdev] Address space extension
...ial example:
>>
>> typedef __attribute__((address_space(**256))) int* gsptr;
>>
>> int *toglobal(gsptr foo)
>> {
>> return (int*)foo;
>> }
>>
>> int load(int *foo)
>> {
>> return *foo;
>> }
>>
>> int loadgs(gsptr foo)
>> {
>> return *foo;
>> }
>>
>> int loadgs2(gsptr foo)
>> {
>> return *toglobal(foo);
>> }
>>
>> When we compile this to LLVM IR with clang (disabling asynchronous unwind
>> tables for clarity), at -O2 we...
2014 Feb 26
2
[LLVMdev] [Valgrind-developers] [GSoC 2014] Using LLVM as a code-generation backend for Valgrind
Hi,
only one letter got to valgrind-developers mailing list. I'll quote
the first message of the thread so that those who do not read llvmdev
knew what's this discusssion about.
=== Begin of the first message ===
> Hi,
>
> I've seen on the LLVM's Open Projet Page [1] an idea about using LLVM to
> generate native code in Valgrind. For what I know, Valgrind uses libVEX