On Fri, Apr 29, 2016 at 4:30 PM, Eric Botcazou wrote:
>> Eh, then the build yawns about the missing mode of the input operand.
>
> Every good back-end has at least an example of this. ;-)
>
>> This is getting a bit frustrating, but attached patch should solve
>> this failure. Again lightly tested,
> Eh, then the build yawns about the missing mode of the input operand.
Every good back-end has at least an example of this. ;-)
> This is getting a bit frustrating, but attached patch should solve
> this failure. Again lightly tested, regtest in progress.
Everything is back to normal with this
On Fri, Apr 29, 2016 at 1:23 PM, Eric Botcazou wrote:
>> Attached patch was actually tested on a couple of cases. It generates
>> the same assembly as before.
>
> Note that you could just remove the second ":W" in the define_insn pattern.
Eh, then the build yawns about the missing mode of the inp
> Attached patch was actually tested on a couple of cases. It generates
> the same assembly as before.
Note that you could just remove the second ":W" in the define_insn pattern.
That's better, but not quite it because this segfaults at -O2:
#0 memory_operand (op=0xabababababababab, mode=mode@e
On Fri, Apr 29, 2016 at 12:17 PM, Eric Botcazou wrote:
>> I'm testing the attached patch. Does it fix your ada failures?
>
> No, it totally breaks stack checking. :-(
Eh, I was trying to be too clever.
Attached patch was actually tested on a couple of cases. It generates
the same assembly as bef
> I'm testing the attached patch. Does it fix your ada failures?
No, it totally breaks stack checking. :-(
=== acats tests ===
FAIL: c52103x
FAIL: c52104x
+FAIL: c52104y
+FAIL: cb1010a
+FAIL: cb1010c
+FAIL: cb1010d
=== acats Summary ===
-# of expected pas
On Fri, Apr 29, 2016 at 9:58 AM, Eric Botcazou wrote:
>> We can put it back, but prehaps implemented as unspec, so it won't
>> interfere with peepholes?
>
> No strong opinion, as long as the final assembly is the same as before.
I'm testing the attached patch. Does it fix your ada failures?
Uros
> We can put it back, but prehaps implemented as unspec, so it won't
> interfere with peepholes?
No strong opinion, as long as the final assembly is the same as before.
--
Eric Botcazou
On Fri, Apr 29, 2016 at 9:47 AM, Eric Botcazou wrote:
>> While looking at the insn enable condition, I noticed that we don't
>> use "probe_stack" pattern any more, as the stack check loop is now
>> implemented in a different way.
>
> Yes, we do, probe_stack is a standard pattern called by the midd
> While looking at the insn enable condition, I noticed that we don't
> use "probe_stack" pattern any more, as the stack check loop is now
> implemented in a different way.
Yes, we do, probe_stack is a standard pattern called by the middle-end.
> 2016-04-28 Uros Bizjak
>
> * config/i386/i
Hello!
Attached patch extends TARGET_READ_MODIFY{,_WRITE} peepholes to handle
all integer modes, while also taking care not to introduce additional
QImode register stalls.
While looking at the insn enable condition, I noticed that we don't
use "probe_stack" pattern any more, as the stack check lo
11 matches
Mail list logo
