Displaying 6 results from an estimated 6 matches for "sputargetlow".
2010 Jun 04
2
[LLVMdev] Heads up: Local register allocator going away
...the scheduler DAG for this BB (llc -view-sched-dags), you can see that the return value CopyFromReg is tied to ADJCALLSTACKUP with a flag, but there is no flag from ADJCALLSTACKUP to BRASL. This allows the scheduler to put other instructions in the gap, and you don't want that.
You should fix SPUTargetLowering::LowerCall to make sure there is an unbroken chain of flag ties between CopyFromReg and BRASL. At least ARM, MBlaze, and Blackfin are doing this, if you need example code.
> This is probably in the SPU backend, as all (most) other backends
> compile the example just fine? Where do I sta...
2010 Jun 08
0
[LLVMdev] Heads up: Local register allocator going away
On Fri, 2010-06-04 at 20:05 +0200, Jakob Stoklund Olesen wrote:
> You should fix SPUTargetLowering::LowerCall to make sure there is an unbroken chain of flag ties between CopyFromReg and BRASL. At least ARM, MBlaze, and Blackfin are doing this, if you need example code.
>
Thanks for the tip. This got fixed in 105601.
And with that, half of the problematic tests appearing with
--regall...
2009 Mar 19
0
[LLVMdev] byte store requires read-modify-write sequence
Hi,
> Our processor only does 32bit reads and writes to memory. Changing a
> byte requires a 32bit read, modify, 32bit write sequence to change the
> 8bit value in memory.
>
> How should this be handled?
your backend will have i32 as a legal type and i8 as an illegal type.
A store to an i8 will be automatically transformed into a "truncating"
to i8 store of i32.
2009 Mar 19
2
[LLVMdev] byte store requires read-modify-write sequence
Our processor only does 32bit reads and writes to memory. Changing a
byte requires a 32bit read, modify, 32bit write sequence to change the
8bit value in memory.
How should this be handled?
Do any of the other current backends do this?
2010 Jun 04
0
[LLVMdev] Heads up: Local register allocator going away
On Thu, 2010-06-03 at 02:53 +0200, Jakob Stoklund Olesen wrote:
> If you are using the local register allocator, please try switching to the fast allocator and report any bugs you find.
>
Tried it, and it seems to break quite a big chunk of our tests on SPU :)
Before r103488 ("Mostly rewrite RegAllocFast") there was no problem.
But with r103488, I get a:
2010 Jun 03
2
[LLVMdev] Heads up: Local register allocator going away
I just changed the default register allocator for -O0 builds to the fast allocator.
This means that the local register allocator is not used anymore, and since it does more or less the same as the fast allocator, there is no reason to keep it around.
I am going to delete it in a week or two.
If you are using the local register allocator, please try switching to the fast allocator and report any