Displaying 20 results from an estimated 23 matches for "load2".
Did you mean:
load
2013 Dec 16
2
[LLVMdev] Question about Pre-RA-schedule in LLVM3.3
...disappear,
this sequence instructions would be executed with less stalls and cycles.
However, in the latest version of LLVM, the Pre-RA-sched builds a scheduling graph(original graph) which is shown following.
//original graph
----> data flow
====> control flow
load1 ----> store1 ====> load2 ----> store2 ====> load3 ----> store3
//end original graph
So, Pre-RA-sched is unable to schedule apart load/store instruction pair.
Due to LiveRange in the Register Allocation stage, all load/store instruction pair are allocated the same register.
If we change the control flow in the abo...
2013 Dec 15
3
[LLVMdev] Question about Pre-RA-schedule in LLVM3.3
...llocated different register from the second instruction.
So, I insert a breakpoint in BuildSchedGraph function in ScheduleDAGSNodes.cpp to debug the source code.
Then I get schedule graph of this basic block:
Like the above graph, Pre-RA-sched(ScheduleRRList.cpp) is unable to insert the 3th SDNode(load2 instruction) between the first SDNode(load1 Instruction) and the second store1 SDNode.
Then in the register allocation step, the pair instruction are allocated same register.
However, if we build a schedule graph like the following:
I think that Pre-RA-sched has change to schedule apart load1 and...
2013 Jan 18
2
[LLVMdev] Weird volatile propagation ?
...r.sroa.0 = alloca i16, align 2
%r.sroa.1 = alloca i16, align 2
store i16 %a, i16* %r.sroa.0, align 2
store i16 1, i16* %r.sroa.1, align 2
%r.sroa.0.0.load3 = load volatile i16* %r.sroa.0, align 2
store volatile i16 %r.sroa.0.0.load3, i16* inttoptr (i64 416 to i16*), align 32
%r.sroa.1.0.load2 = load volatile i16* %r.sroa.1, align 2
store volatile i16 %r.sroa.1.0.load2, i16* inttoptr (i64 418 to i16*), align 2
ret void
}
When I would have expected something like :
define void @test(i16 zeroext %a) nounwind uwtable {
store volatile i16 %a, i16* inttoptr (i64 416 to i16*), align 2...
2013 Dec 21
0
[LLVMdev] Question about Pre-RA-schedule in LLVM3.3
...instructions would be executed with less stalls and cycles.
> However, in the latest version of LLVM, the Pre-RA-sched builds a scheduling graph(original graph) which is shown following.
> //original graph
> ----> data flow
> ====> control flow
> load1 ----> store1 ====> load2 ----> store2 ====> load3 ----> store3
> //end original graph
> So, Pre-RA-sched is unable to schedule apart load/store instruction pair.
> Due to LiveRange in the Register Allocation stage, all load/store instruction pair are allocated the same register.
>
> If we change th...
2013 Jan 20
0
[LLVMdev] codegen of volatile aggregate copies (was "Weird volatile propagation" on llvm-dev)
...r.sroa.0 = alloca i16, align 2
%r.sroa.1 = alloca i16, align 2
store i16 %a, i16* %r.sroa.0, align 2
store i16 1, i16* %r.sroa.1, align 2
%r.sroa.0.0.load3 = load volatile i16* %r.sroa.0, align 2
store volatile i16 %r.sroa.0.0.load3, i16* inttoptr (i64 416 to i16*), align 32
%r.sroa.1.0.load2 = load volatile i16* %r.sroa.1, align 2
store volatile i16 %r.sroa.1.0.load2, i16* inttoptr (i64 418 to i16*), align 2
ret void
}
The problem is in how clang codegen aggregate copies when the source or
the destination are volatile : it uses the memcpy intrinsic, setting the
volatile parameter....
2013 Jan 28
4
[LLVMdev] Specify the volatile access behaviour of the memcpy, memmove and memset intrinsics
...r.sroa.0 = alloca i16, align 2
%r.sroa.1 = alloca i16, align 2
store i16 %a, i16* %r.sroa.0, align 2
store i16 1, i16* %r.sroa.1, align 2
%r.sroa.0.0.load3 = load volatile i16* %r.sroa.0, align 2
store volatile i16 %r.sroa.0.0.load3, i16* inttoptr (i64 416 to i16*), align 32
%r.sroa.1.0.load2 = load volatile i16* %r.sroa.1, align 2
store volatile i16 %r.sroa.1.0.load2, i16* inttoptr (i64 418 to i16*), align 2
ret void
}
In the generated ir, the loads are marked as volatile. In this case,
this is due to the new SROA being conservatively correct. We should
however expect the test fun...
2012 Jul 16
10
Cómo hacer un source de manera "elegante"
Hola de nuevo:
Veamos...
Tengo mi aplicación organizada en varios módulos .r, de tal modo que una vez que los tengo cargados (mediante source("Load.R")) el usuario puede disfrutar de las funcionalidades llamando directamente a una serie de funciones que realizan análisis y generan resultados (numéricos y gráficos).
El caso es que me gustaría "elegantizar" esa carga inicial
2013 Dec 15
0
[LLVMdev] Question about Pre-RA-schedule in LLVM3.3
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
> On Behalf Of Haishan
> Subject: [LLVMdev] Question about Pre-RA-schedule in LLVM3.3
> My clang version is 3.3 and debug build.
> //test.c
> int a[6] = {1, 2, 3, 4, 5, 6}
> int main() {
> a[0] = a[5];
> a[1] = a[4];
> a[2] = a[5];
> }
> //end test.c
> Then test.dump is
2017 Mar 09
4
[RFC] bitfield access shrinking
...0, align 8
%bf.clear = and i64 %bf.load, -65536
%bf.set = or i64 %bf.value, %bf.clear
store i64 %bf.set2, i64* %9, align 8
.....
%bf.load1 = load i64, i64* %0, align 8
%bf.clear1 = and i64 %bf.load1, -4294901761
%bf.set1 = or i64 %bf.value1, %bf.clear1
store i64 %bf.set2, i64* %9, align 8
.....
%bf.load2 = load i64, i64* %0, align 8
%bf.clear2 = and i64 %bf.load2, -4294901761
%bf.set2 = or i64 %bf.value2, %bf.clear2
store i64 %bf.set2, i64* %9, align 8
After coalescing, it will become:
%bf.load = load i64, i64* %0, align 8
%bf.clear = and i64 %bf.load, -65536
%bf.set = or i64 %bf.value, %bf.clear...
2013 Jan 20
2
[LLVMdev] [cfe-dev] codegen of volatile aggregate copies (was "Weird volatile propagation" on llvm-dev)
...%r.sroa.1 = alloca i16, align 2
> store i16 %a, i16* %r.sroa.0, align 2
> store i16 1, i16* %r.sroa.1, align 2
> %r.sroa.0.0.load3 = load volatile i16* %r.sroa.0, align 2
> store volatile i16 %r.sroa.0.0.load3, i16* inttoptr (i64 416 to i16*),
> align 32
> %r.sroa.1.0.load2 = load volatile i16* %r.sroa.1, align 2
> store volatile i16 %r.sroa.1.0.load2, i16* inttoptr (i64 418 to i16*),
> align 2
>
Just so we're on the same page, the "regression" (which I claim is actually
a bug-fix) are the loads here being volatile in addition to the stores....
2013 Jan 29
0
[LLVMdev] Specify the volatile access behaviour of the memcpy, memmove and memset intrinsics
...lign 2
> %r.sroa.1 = alloca i16, align 2
> store i16 %a, i16* %r.sroa.0, align 2
> store i16 1, i16* %r.sroa.1, align 2
> %r.sroa.0.0.load3 = load volatile i16* %r.sroa.0, align 2
> store volatile i16 %r.sroa.0.0.load3, i16* inttoptr (i64 416 to i16*), align 32
> %r.sroa.1.0.load2 = load volatile i16* %r.sroa.1, align 2
> store volatile i16 %r.sroa.1.0.load2, i16* inttoptr (i64 418 to i16*), align 2
> ret void
> }
>
> In the generated ir, the loads are marked as volatile. In this case,
> this is due to the new SROA being conservatively correct. We should...
2017 Mar 09
4
[RFC] bitfield access shrinking
...ue, %bf.clear
>> store i64 %bf.set2, i64* %9, align 8
>> .....
>> %bf.load1 = load i64, i64* %0, align 8
>> %bf.clear1 = and i64 %bf.load1, -4294901761
>> %bf.set1 = or i64 %bf.value1, %bf.clear1
>> store i64 %bf.set2, i64* %9, align 8
>> .....
>> %bf.load2 = load i64, i64* %0, align 8
>> %bf.clear2 = and i64 %bf.load2, -4294901761
>> %bf.set2 = or i64 %bf.value2, %bf.clear2
>> store i64 %bf.set2, i64* %9, align 8
>>
>> After coalescing, it will become:
>> %bf.load = load i64, i64* %0, align 8
>> %bf.clear = a...
2004 Oct 05
0
Asterisk CLI Prompt : Small hack
...o get
it working.
Flames/comments/suggestions:
Matt or Matt
flewid@flewid.ca sideshow@terahertz.net
now you can use %n in your prompts to give a newline. A prompt example
is below.
export ASTERISK_PROMPT="%n[ %d/%t ]%n[ Load1: %l1 Load2: %l2 Load3: %l3
]%n[ Processes: %l4 PID: %l5 ]%n[ %H ] %%%# "
or
env ASTERISK_PROMPT="%n[ %d/%t ]%n[ Load1: %l1 Load2: %l2 Load3: %l3
]%n[ Processes: %l4 PID: %l5 ]%n[ %H ] %%%# "
--- begin patch [ apply in asterisk/ with patch -p0 < ]
--- asterisk.c.original 2004-10-05 10:26:...
2017 Mar 09
3
[RFC] bitfield access shrinking
...ue, %bf.clear
>> store i64 %bf.set2, i64* %9, align 8
>> .....
>> %bf.load1 = load i64, i64* %0, align 8
>> %bf.clear1 = and i64 %bf.load1, -4294901761
>> %bf.set1 = or i64 %bf.value1, %bf.clear1
>> store i64 %bf.set2, i64* %9, align 8
>> .....
>> %bf.load2 = load i64, i64* %0, align 8
>> %bf.clear2 = and i64 %bf.load2, -4294901761
>> %bf.set2 = or i64 %bf.value2, %bf.clear2
>> store i64 %bf.set2, i64* %9, align 8
>>
>> After coalescing, it will become:
>> %bf.load = load i64, i64* %0, align 8
>> %bf.clear = a...
2013 Jan 21
0
[LLVMdev] [cfe-dev] codegen of volatile aggregate copies (was "Weird volatile propagation" on llvm-dev)
...6, align 2
> store i16 %a, i16* %r.sroa.0, align 2
> store i16 1, i16* %r.sroa.1, align 2
> %r.sroa.0.0.load3 = load volatile i16* %r.sroa.0, align 2
> store volatile i16 %r.sroa.0.0.load3, i16* inttoptr (i64 416 to
> i16*), align 32
> %r.sroa.1.0.load2 = load volatile i16* %r.sroa.1, align 2
> store volatile i16 %r.sroa.1.0.load2, i16* inttoptr (i64 418 to
> i16*), align 2
>
>
> Just so we're on the same page, the "regression" (which I claim is
> actually a bug-fix) are the loads here being volatile in ad...
2013 Jan 31
0
[LLVMdev] Specify the volatile access behaviour of the memcpy, memmove and memset intrinsics
...> %r.sroa.1 = alloca i16, align 2
> store i16 %a, i16* %r.sroa.0, align 2
> store i16 1, i16* %r.sroa.1, align 2
> %r.sroa.0.0.load3 = load volatile i16* %r.sroa.0, align 2
> store volatile i16 %r.sroa.0.0.load3, i16* inttoptr (i64 416 to i16*), align 32
> %r.sroa.1.0.load2 = load volatile i16* %r.sroa.1, align 2
> store volatile i16 %r.sroa.1.0.load2, i16* inttoptr (i64 418 to i16*), align 2
> ret void
> }
>
> In the generated ir, the loads are marked as volatile. In this case,
> this is due to the new SROA being conservatively correct. We shoul...
2008 Jun 17
4
PCA analysis
Hi,
I have a problem with making PCA plots that are readable.
I would like to set different sympols instead of the numbers of my samples or their names, that I get plotted (xlabs).
How is this possible? With points, i don´t seem to get the right data plotted onto the PCA plot, as I do not quite understand from where it is taken. I dont know how to
plot the correct columns of the prcomp
2013 Feb 03
0
[LLVMdev] Specify the volatile access behaviour of the memcpy, memmove and memset intrinsics
...alloca i16, align 2
>> store i16 %a, i16* %r.sroa.0, align 2
>> store i16 1, i16* %r.sroa.1, align 2
>> %r.sroa.0.0.load3 = load volatile i16* %r.sroa.0, align 2
>> store volatile i16 %r.sroa.0.0.load3, i16* inttoptr (i64 416 to i16*), align 32
>> %r.sroa.1.0.load2 = load volatile i16* %r.sroa.1, align 2
>> store volatile i16 %r.sroa.1.0.load2, i16* inttoptr (i64 418 to i16*), align 2
>> ret void
>> }
>>
>> In the generated ir, the loads are marked as volatile. In this case,
>> this is due to the new SROA being conserva...
1997 May 29
2
R-beta: WISH: For dyn.load()ing, I'd like is.loaded(.) , symbol.C, symbol.For
...oaded.
S+>>
S+>> The symbol.S function is only useful for those who have
S+>> old-S (S-PLUS version 1.x) functions (not macros) and do
S+>> not wish to convert them to .Fortran calls.
S+>>
S+>> SEE ALSO:
S+>> dyn.load, dyn.load2, LOAD, .Fortran, .S.
S+>>
S+>> EXAMPLES:
S+>> if (!is.loaded(symbol.C("mbol")))
S+>> dyn.load("/usr/mabel/mbol.o")
S+>> .C("mbol",as.double(x),as.integer(length(x)))
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-...
2004 Jan 20
3
Changing workspace from within an R session
Hello R-users,
is it possible to navigate from one workspace to the other from within an R
session or does one has to close R and restart it from the directory where
resides the desired workspace?
For example from Splus I have this little function, see at the end, which I
used all the time to navigate between valid Splus directories. I find this
particularly usefull when I develop new