But I don't think that's enough, with the current loop it would strip the
subreg of a multiword subreg and there is some logic in df_ref_record,
which wouldn't see it. An alternative might be:
while (GET_CODE (dst) == STRICT_LOW_PART
|| GET_CODE (dst) == ZERO_EXTRACT)
{
f
Richard Sandiford wrote:
Paolo Bonzini <[EMAIL PROTECTED]> writes:
My opinion:
(set (subreg:HI (reg:SI) 2) ...
DF_REF_READ_WRITE?
yep, only case without PARTIAL
Sorry if this is a daft question, but why would it be treated as a read?
I thought that without strict_lowpart, this sort of subreg
Paolo Bonzini <[EMAIL PROTECTED]> writes:
> My opinion:
>>> (set (subreg:HI (reg:SI) 2) ...
>>> DF_REF_READ_WRITE?
>
> yep, only case without PARTIAL
Sorry if this is a daft question, but why would it be treated as a read?
I thought that without strict_lowpart, this sort of subreg assignment
was m
The rules should be simple. Bits of the dest reg survive only if one of
the following is true.
- there is a STRICT_LOW_PART (of a SUBREG)
- there is a ZERO_EXTRACT (not necessarily of a SUBREG!)
- the subreg is part of a multiword subreg
So, this is a prototype patch that I would like to
Hi,
On Fri, 11 May 2007, Paolo Bonzini wrote:
> First of all, scrap my other message...
>
> > There was a debate several months ago on this issue: how much should the
> > df scanner be a theorem prover with respect to how many bits survive an
> > operation.
> > For instance, I could easily add t
Hi,
On Fri, 11 May 2007, Kenneth Zadeck wrote:
> There was a debate several months ago on this issue: how much should the
> df scanner be a theorem prover with respect to how many bits survive an
> operation.
> For instance, I could easily add to your list, anding and oring
> operations which als
First of all, scrap my other message...
There was a debate several months ago on this issue: how much should the
df scanner be a theorem prover with respect to how many bits survive an
operation.
For instance, I could easily add to your list, anding and oring
operations which also preserve bits.
Hi,
On Fri, 11 May 2007, Rask Ingemann Lambertsen wrote:
>The first one is the insn pattern right below the mulsidi3 expander,
>right? Please give all insn patterns a name to make searches easier.
It's on the TODO list. :)
>May I ask why the original insn 7 isn't coded something lik
My opinion:
(set (subreg:SI (reg:DI) 4) ...
DF_REF_READ_WRITE|DF_REF_PARTIAL?
yep
(set (subreg:HI (reg:DI) 6) ...
DF_REF_READ_WRITE?
Also PARTIAL. you can rely on the content of the 0-3 word.
Likewise for:
(set (subreg:HI (reg:DI) 2) ...
here you can rely on the content of the 4-7 wo
On Thu, May 10, 2007 at 07:43:19PM +0200, Roman Zippel wrote:
> Looking closer at this I don't think strict_low_part should be required
> as splitting DI registers produces a lot of (subreg:SI (reg:DI)) even as
> destination, but they only set strictly part of the register. If I look
> through i38
Roman Zippel wrote:
> Hi,
>
> On Thu, 10 May 2007, I wrote:
>
>
>> I have a few problems with the m68k mulsidi3 pattern on the dataflow
>> branch.
>>
>
> To illustrate the problem here is what happens during combine:
>
> -(insn 7 28 8 2 ../gcc/gcc/testsuite/gcc.c-torture/execute/20001108-1.
On Fri, May 11, 2007 at 01:54:24PM +0200, Roman Zippel wrote:
>
> To illustrate the problem here is what happens during combine:
>
> -(insn 7 28 8 2 ../gcc/gcc/testsuite/gcc.c-torture/execute/20001108-1.c:4
> (parallel [
> -(set (subreg:SI (reg:DI 30 [ D.1547 ]) 4)
> -
Hi,
On Thu, 10 May 2007, I wrote:
> I have a few problems with the m68k mulsidi3 pattern on the dataflow
> branch.
To illustrate the problem here is what happens during combine:
-(insn 7 28 8 2 ../gcc/gcc/testsuite/gcc.c-torture/execute/20001108-1.c:4
(parallel [
-(set (subreg:SI (
Hi,
I have a few problems with the m68k mulsidi3 pattern on the dataflow
branch.
Currently incorrect code is generated as the DF_REF_PARTIAL bit isn't
set for its destinations and dataflow thinks both set the register
completely, thus one destination is set to unused. I could change the
pattern to
14 matches
Mail list logo
