store double-cvtd-to-int to memory

store double-cvtd-to-int to memory

[Dale Johannesen]

I'm trying to get PPC to generate a more efficient sequence for the
case where you want to put the result of double-to-int conversion in
memory, and don't need it in a register.  The normal code looks
like cvt in FP reg, store to temp mem, load to int reg, store to
the real location.   There is an instruction to do it directly,
though, without going through temp mem.  I thought getting
combine to do it looked right, and wrote this pattern, which is
just fix_truncdfsi2 with the result fed into a store:

   [(set (match_operand:SI 0 "memory_operand" "=m")
         (fix:SI (match_operand:DF 1 "gpc_reg_operand" "f")))
    (clobber (match_operand:DI 2 "gpc_reg_operand" "=f"))
    (clobber (match_operand:DI 3 "memory_operand" "=o"))]

where op3 is a stack temp.
Unfortunately combine refuses to generate this pattern; it is afraid
the two parallel memory_operands might conflict (which we can see they
don't), and doesn't even attempt to do alias checking.  So what is Plan 
B?
Putting alias checking into combine seems like a big hammer (for that
matter, I don't think there's enough alias info in the stack-temp to
get this right anyway).  Is there an alternative general approach?

Re: store double-cvtd-to-int to memory

[Richard Henderson]

On Wed, Mar 12, 2003 at 05:45:36PM -0800, Dale Johannesen wrote:
>   [(set (match_operand:SI 0 "memory_operand" "=m")
>         (fix:SI (match_operand:DF 1 "gpc_reg_operand" "f")))
>    (clobber (match_operand:DI 2 "gpc_reg_operand" "=f"))
>    (clobber (match_operand:DI 3 "memory_operand" "=o"))]
> 
> where op3 is a stack temp.

Do you actually need the stack temp?  I understood you that
you didn't need it, because you had an instruction for this
directly.  If not, just leave it out.


r~

Re: store double-cvtd-to-int to memory

[Dale Johannesen]

On Thursday, March 13, 2003, at 02:32  PM, Richard Henderson wrote:

> On Wed, Mar 12, 2003 at 05:45:36PM -0800, Dale Johannesen wrote:
>>   [(set (match_operand:SI 0 "memory_operand" "=m")
>>         (fix:SI (match_operand:DF 1 "gpc_reg_operand" "f")))
>>    (clobber (match_operand:DI 2 "gpc_reg_operand" "=f"))
>>    (clobber (match_operand:DI 3 "memory_operand" "=o"))]
>>
>> where op3 is a stack temp.
>
> Do you actually need the stack temp?  I understood you that
> you didn't need it, because you had an instruction for this
> directly.  If not, just leave it out.

Thanks.
For this case, where the result goes in memory, you don't need a stack 
temp.
For the case where it goes in a register, however, you do.  (It looks 
like
this is not so on Alpha?)  So removing op3 from the above pattern 
results
in another pattern that combine won't generate, because the original
fix_truncdfsi2 pattern does have the temp, and needs it.

Re: store double-cvtd-to-int to memory

[David Edelsohn]

	Can't you just mark the unnecessary temp with "X" constraint for
the pattern that does not need it?

David

Re: store double-cvtd-to-int to memory

[Geoff Keating]

David Edelsohn <dje@watson.ibm.com> writes:

> 	Can't you just mark the unnecessary temp with "X" constraint for
> the pattern that does not need it?

That would be a good idea, but doesn't solve Dale's problem...

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: store double-cvtd-to-int to memory

[Dale Johannesen]

On Friday, March 14, 2003, at 11:37  AM, Geoff Keating wrote:
> David Edelsohn <dje@watson.ibm.com> writes:
>
>> 	Can't you just mark the unnecessary temp with "X" constraint for
>> the pattern that does not need it?
>
> That would be a good idea, but doesn't solve Dale's problem...

Right.  The problem is not that the pattern isn't recognized, it's
that combine won't consider it in the first place.
(I did run this by Geoff before asking the list, btw, which
makes me think it's not a case of me missing something trivial.)
Basically I'm trying to get combine to merge these 2 patterns:

(insn 11 10 12 0 0x0 (set (mem:SI (reg:SI 5 r5) [0 S4 A32])
         (reg:SI 120)) 309 {*movsi_internal1} (insn_list 10 (nil))

(insn 10 5 11 0 0x0 (parallel [
             (set (reg:SI 120)
                 (fix:SI (reg:DF 33 f1)))
             (clobber (reg:DI 121))
             (clobber (mem/f:DI (plus:SI (reg/f:SI 30 r30)
                         (const_int 32 [0x20])) [0 S8 A64]))

It considers generating
(insn 10 5 11 0 0x0 (parallel [
             (set (mem:SI (reg:SI 5 r5)
                 (fix:SI (reg:DF 33 f1)))
             (clobber (reg:DI 121))
             (clobber (mem/f:DI (plus:SI (reg/f:SI 30 r30)
                         (const_int 32 [0x20])) [0 S8 A64]))
and rejects that because it thinks the mem's might conflict, as I said 
before.
It also considers generating
             (set (mem:SI (reg:SI 5 r5)
                 (fix:SI (reg:DF 33 f1)))
which isn't adequate because I *do* need the floating point scratch reg.
It does not consider generating
(insn 10 5 11 0 0x0 (parallel [
             (set (mem:SI (reg:SI 5 r5)
                 (fix:SI (reg:DF 33 f1)))
             (clobber (reg:DI 121))]
which is what I want.
(Not that it has anything to do with this problem, but why is the 
scratch
reg DI not DF?)

Re: store double-cvtd-to-int to memory

[Richard Henderson]

On Fri, Mar 14, 2003 at 10:51:22AM -0800, Dale Johannesen wrote:
> For the case where it goes in a register, however, you do. 
> (It looks like this is not so on Alpha?)

Well, Alpha's a bit different.  We can convert to DImode
without memory, but truncating to SImode needs special 
care.  Without the above pattern, we'd store the DImode
back to the stack, load with an integer register, then
store the truncated value.

So the match is for an SImode store to memory.

But the concept should be the same.

> So removing op3 from the above pattern results in another pattern
> that combine won't generate, because the original
> fix_truncdfsi2 pattern does have the temp, and needs it.

Um, that's wrong.  Part of what combine does is to discard
clobbers and add them back as needed.  Why isn't that happening?


r~

Re: store double-cvtd-to-int to memory

[Richard Henderson]

You might also want to look at Alpha's pattern for this:

(define_insn_and_split "*fix_truncdfsi_internal"
  [(set (match_operand:SI 0 "memory_operand" "=m")
        (subreg:SI (fix:DI (match_operand:DF 1 "reg_or_0_operand" "fG")) 0))
   (clobber (match_scratch:DI 2 "=f"))]
  "TARGET_FP && alpha_fptm < ALPHA_FPTM_SU"
  "#"
  "&& reload_completed"
  [(set (match_dup 2) (fix:DI (match_dup 1)))
   (set (match_dup 3) (unspec:SI [(match_dup 2)] UNSPEC_CVTQL))
   (set (match_dup 0) (match_dup 3))]
  ;; Due to REG_CANNOT_CHANGE_SIZE issues, we cannot simply use SUBREG.
  "operands[3] = gen_rtx_REG (SImode, REGNO (operands[2]));"
  [(set_attr "type" "fadd")
   (set_attr "trap" "yes")])



r~

Re: store double-cvtd-to-int to memory

[Dale Johannesen]

(my mail file was clobbered so this may not thread properly.
see here for context:)
http://gcc.gnu.org/ml/gcc/2003-03/msg00802.html

On Fri, Mar 14  rth wrote:
> On Fri, Mar 14, 2003 at 10:51:22AM -0800, Dale Johannesen wrote:
> > For the case where it goes in a register, however, you do.
> > (It looks like this is not so on Alpha?)
>
> Well, Alpha's a bit different.  We can convert to DImode
> without memory, but truncating to SImode needs special
> care.  Without the above pattern, we'd store the DImode
> back to the stack, load with an integer register, then
> store the truncated value.
>
> So the match is for an SImode store to memory.
>
> But the concept should be the same.
>
> > So removing op3 from the above pattern results in another pattern
> > that combine won't generate, because the original
> > fix_truncdfsi2 pattern does have the temp, and needs it.
>
> Um, that's wrong.  Part of what combine does is to discard
> clobbers and add them back as needed.  Why isn't that happening?

It's not happening because that mechanism only works on clobbers
of registers (or scratch regs), not of memory.  Comments make
clear this is intentional.  Thus, the Alpha case isn't really
analogous.  I could try to make it work on memory
clobbers if it is safe to do that.  Are the semantics of memory
clobbers equivalent to "scratch memory" for that insn only?
Or might there be side effects?

Another approach I thought of is to break the fix_trunc differently
to begin with:

(define_expand "fix_truncdfsi2"
   [(set (match_operand:DI 2 "gpc_reg_operand" "")
         (unspec:DI [(fix:SI (match_operand:DF 1 "gpc_reg_operand" ""))] 
10))
    (parallel [
         (set (match_operand:SI 0 "gpc_reg_operand" "")
              (unspec:SI [(match_dup 2)] 12))
         (clobber (match_dup 3))])]

where the first set is the "fctiwz" insn, producing a DF result,
and the second represents store 64 bit value to memory, load back low 
32 bits.
Then I try to combine the first set with a store to SI memory, but so 
far
I haven't found a way to outwit the type checking, which doesn't let me
store a 64 bit value into 32 bits...

There must be some way to do this.  Thanks all.

Re: Name of front-end

[Richard Kenner]

    FWIW, some IBM 360 PL/1 manuals I just looked at do not mark or claim
    "PL/1" as trademark.  

But certainly some did.  And contemporary lore was that they trademarked PL/2,
PL/3, etc ...

Re: Name of front-end

[Robert Dewar]

Richard Kenner wrote:

>     FWIW, some IBM 360 PL/1 manuals I just looked at do not mark or claim
>     "PL/1" as trademark.  
> 
> But certainly some did.  And contemporary lore was that they trademarked PL/2,
> PL/3, etc ...

Hmm, Richard, what is your authority/reference for this? I can find no 
evidence that PL/I was trademarked. I very much doubt that PL/1 is 
trademarked since IBM always uses PL/I (letter I), not PL/1 (digit 1) in 
their product literature

As for PL/2 etc, that's surely bogus, since such names were never used
in commerce (a requirement for trademarking something!)

If you google on PL/I you will find zillions of references from third
parties with no hint of a trademark, so I think you can safetly talk
about GNU PL/1 without worrying!

Re: Name of front-end

[Andrew Haley]

Robert Dewar writes:

 > If you google on PL/I you will find zillions of references from third
 > parties with no hint of a trademark, so I think you can safetly talk
 > about GNU PL/1 without worrying!

Trademark law is complex, I strongly advise against anyone giving
amateur legal opinions in this area :-)

Re: Name of front-end

[Robert Dewar]

Andrew Haley wrote:

> Robert Dewar writes:
> 
>  > If you google on PL/I you will find zillions of references from third
>  > parties with no hint of a trademark, so I think you can safetly talk
>  > about GNU PL/1 without worrying!
> 
> Trademark law is complex, I strongly advise against anyone giving
> amateur legal opinions in this area :-)

Umm, I don't think you need a lawyer to tell you that it a name is
not trademarked, then using it will not be a trademark infringement :-)

Re: Name of front-end

[Laurent GUERBY]

On Tue, 2003-12-09 at 00:31, Robert Dewar wrote:
> Umm, I don't think you need a lawyer to tell you that it a name is
> not trademarked, then using it will not be a trademark infringement :-)

Sure, ask the MobiliX folks. MobiliX is not trademarked, Asterix
and Obelix are, since the words are "close enough" German courts
ruled that they were violating the existing trademarks. 

Now you've just expanded the "name is not trademarked" by 
"name is not close enough from existing trademark following existing
rulings in various countries", and you need a lawyer
to do the search. (MobiliX is trying to get the ruling
reversed in various ways, estimated legal cost is around 60 000 USD).

Unfortunate state of affair.

Laurent

Re: Name of front-end

[Robert Dewar]

Laurent GUERBY wrote:

> On Tue, 2003-12-09 at 00:31, Robert Dewar wrote:
> 
>>Umm, I don't think you need a lawyer to tell you that it a name is
>>not trademarked, then using it will not be a trademark infringement :-)
> 
> 
> Sure, ask the MobiliX folks. MobiliX is not trademarked, Asterix
> and Obelix are, since the words are "close enough" German courts
> ruled that they were violating the existing trademarks. 

Indeed the german courts are rather notorious here. My comments are
strictly with respect to US case law :-)

Re: Name of front-end

[Daniel Berlin]

On Dec 8, 2003, at 6:31 PM, Robert Dewar wrote:

> Andrew Haley wrote:
>
>> Robert Dewar writes:
>>  > If you google on PL/I you will find zillions of references from 
>> third
>>  > parties with no hint of a trademark, so I think you can safetly 
>> talk
>>  > about GNU PL/1 without worrying!
>> Trademark law is complex, I strongly advise against anyone giving
>> amateur legal opinions in this area :-)
>
> Umm, I don't think you need a lawyer to tell you that it a name is
> not trademarked, then using it will not be a trademark infringement :-)

Remember, just because it's not a *registered* trademark, doesn't make 
it not a trademark. You simply have to use it in trade for it to be a 
trademark. Though of course, registration gives you benefits. In the 
US, anyway.
http://www.uspto.gov/web/offices/tac/doc/basic/register.htm

(The PTO, BTW, has the most worthless website on the planet. They made 
it look nicer recently, but didn't make any information easier to 
access. Zen and the art of redesigning government websites, i guess).

Re: Name of front-end

[Dale Johannesen]

[-- Attachment #1: Type: text/plain, Size: 546 bytes --]

On Dec 8, 2003, at 8:32 AM, Richard Kenner wrote:
>     FWIW, some IBM 360 PL/1 manuals I just looked at do not mark or 
> claim
>     "PL/1" as trademark.
>
> But certainly some did.  And contemporary lore was that they 
> trademarked PL/2,
> PL/3, etc ...

I've heard this also, but it may well be a myth.   Here
http://www-3.ibm.com/software/data/ims/v5pdf/DFSI10C6.PDF.
is an IBM manual, which talks about PL/I and contains a list of IBM
trademarks (p. 13 according to Acrobat, or xi according to the 
document),
and PL/I is not one of them.

[-- Attachment #2: Type: text/enriched, Size: 710 bytes --]

On Dec 8, 2003, at 8:32 AM, Richard Kenner wrote:

<excerpt>    FWIW, some IBM 360 PL/1 manuals I just looked at do not
mark or claim

    "PL/1" as trademark.  


But certainly some did.  And contemporary lore was that they
trademarked PL/2,

PL/3, etc ...

</excerpt>

I've heard this also, but it may well be a myth.   Here

<fontfamily><param>Arial</param><color><param>0000,0000,FFFF</param><x-tad-bigger>http://www-3.ibm.com/software/data/ims/v5pdf/DFSI10C6.PDF</x-tad-bigger></color><x-tad-bigger>.

</x-tad-bigger></fontfamily>is an IBM manual, which talks about PL/I
and contains a list of IBM

trademarks (p. 13 according to Acrobat, or xi according to the
document), 

and PL/I is not one of them.

Re: Name of front-end

[Felix Lee]

search at www.uspto.gov doesn't turn up any current or historical
trademarks for "pl/1" or "pl/i" or "pl/2" by IBM.  not sure the
limitations of that database, but it does include dead trademarks
earlier than 1960.
--

Re: [GCC] Re: Name of front-end

[Trevor Jenkins]

On Mon, 8 Dec 2003, Dale Johannesen <dalej@apple.com> wrote:

> On Dec 8, 2003, at 8:32 AM, Richard Kenner wrote:
> > FWIW, some IBM 360 PL/1 manuals I just looked at do not mark or
> > claim "PL/1" as trademark.
> >
> > But certainly some did.  And contemporary lore was that they
> > trademarked PL/2,
> > PL/3, etc ...
>
> I've heard this also, but it may well be a myth.   Here
> http://www-3.ibm.com/software/data/ims/v5pdf/DFSI10C6.PDF.

Looking through the September 2002 ediion of the Visual Age PL/1 Language
Reference Manual, which is available via a similar URL, the list of IBM
trademarks is slightly different. Including, probably much to Sony's
chagrine, PS/2. But as with the one cited above does not mention PL/1.

An anecdotal appeal to a single source isn't sufficient.

It should be borne in mind that these manuals are copyright by IBM.

Regards, Trevor

<>< Re: deemed!