Displaying 7 results from an estimated 7 matches for "r511".
Did you mean:
511
2016 Aug 22
3
Instruction itineraries and fence/barrier instructions
...2 r1, r1, %lo(write_me)
store r0, r1, 0, 32
fence 2
movimm r0, %hi(read_me), 64
movimmshf32 r0, r0, %lo(read_me)
load r1, r0, 0, 32
bitop1 r509, r510, 0, OR, 64
load r510, r509, 0, 64
addI r509, r509, 16, 64
jabs r511
Note the separation between the store prior to the fence and the code that
comes after.
Now that we've got itineraries in place we see:
subI r509, r509, 16, 64
store r510, r509, 0, 64
bitop1 r510, r509, 0, OR, 64
movimm r1, %hi(write_me), 64
store...
2016 Aug 22
2
Instruction itineraries and fence/barrier instructions
...> > movimm r0, %hi(read_me), 64
> > movimmshf32 r0, r0, %lo(read_me)
> > load r1, r0, 0, 32
> > bitop1 r509, r510, 0, OR, 64
> > load r510, r509, 0, 64
> > addI r509, r509, 16, 64
> > jabs r511
> >
> > Note the separation between the store prior to the fence and the code
> that comes after.
> >
> > Now that we've got itineraries in place we see:
> >
> > subI r509, r509, 16, 64
> > store r510, r509, 0, 64
> > bito...
2016 Nov 03
2
rotl: undocumented LLVM instruction?
...& and there ends up giving us suboptimal results
as compared with 3.6.
For example, in 3.6 the generated code is simply:
bclr64: # @bclr64
# BB#0: # %entry
addI r1, r1, -1, 64
bclr r1, r0, r1, 64
jabs r511
Whereas with 3.9 the generated code is:
bclr64: # @bclr64
# BB#0: # %entry
addI r1, r1, -1, 64
movimm r2, -2, 64
rol r1, r2, r1, 64
bitop1 r1, r0, r1, AND, 64
jabs r511
... it seem...
2016 Nov 03
3
rotl: undocumented LLVM instruction?
...3.6.
>>
>> For example, in 3.6 the generated code is simply:
>>
>> bclr64: # @bclr64
>> # BB#0: # %entry
>> addI r1, r1, -1, 64
>> bclr r1, r0, r1, 64
>> jabs r511
>>
>> Whereas with 3.9 the generated code is:
>>
>> bclr64: # @bclr64
>> # BB#0: # %entry
>> addI r1, r1, -1, 64
>> movimm r2, -2, 64
>> rol r1, r2, r1, 64
&g...
2016 Nov 03
2
rotl: undocumented LLVM instruction?
...in 3.6 the generated code is simply:
>
> bclr64: # @bclr64
> # BB#0: # %entry
> addI r1, r1, -1, 64
> bclr r1, r0, r1, 64
> jabs r511
>
> Whereas with 3.9 the generated code is:
>
> bclr64: # @bclr64
> # BB#0: # %entry
> addI r1, r1, -1, 64
> movimm r2, -2, 64
>...
2007 Sep 04
11
returning(...) ?
The following construct is an ActiveSupport-ism:
returning(Foo.new) do |foo|
...
end
I don''t especially like it, since it''s both more verbose and less efficient
than the direct alternative:
foo = Foo.new
...
foo
It doesn''t occur many times in Merb, so does anyone agree with me that it
should be removed?
I tried doing this (patch attached) and I find
2016 Nov 02
3
rotl: undocumented LLVM instruction?
We've recently moved our project from LLVM 3.6 to LLVM 3.9. I noticed one
of our code generation tests is breaking in 3.9.
The test is:
; RUN: llc < %s -march=xstg | FileCheck %s
define i64 @bclr64(i64 %a, i64 %b) nounwind readnone {
entry:
; CHECK: bclr r1, r0, r1, 64
%sub = sub i64 %b, 1
%shl = shl i64 1, %sub
%xor = xor i64 %shl, -1
%and = and i64 %a, %xor
ret i64