public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: msokolov@ivan.Harhan.ORG (Michael Sokolov)
To: gcc@gcc.gnu.org
Subject: Re: FWIW: VAX fix backport and gcc built on 4.3BSD first time ever!
Date: Thu, 21 Dec 2000 21:53:00 -0000	[thread overview]
Message-ID: <0012220550.AA02184@ivan.Harhan.ORG> (raw)

John David Anglin <dave@hiauly1.hia.nrc.ca> wrote:

> Here is a revised patch for the mainline vax.md.  The bootstrap with
> this patch looks like it is going ok, although it is far from complete.
> I will submit the patch formally when I am certain that it is ok.

Thanks for all the work!

A few comments on the call and call_value patterns, though:

> +(define_insn "call"
>    [(call (match_operand:QI 0 "memory_operand" "m")
> -	 (match_operand:SI 1 "const_int_operand" "n"))
> -   (set (reg:SI 14) (reg:SI 14))]
> +	 (const_int 0))]
>
> [...]
>
> +(define_insn "call_value"
>    [(set (match_operand 0 "" "=g")
>  	(call (match_operand:QI 1 "memory_operand" "m")
> -	      (match_operand:SI 2 "const_int_operand" "n")))
> -   (set (reg:SI 14) (reg:SI 14))]
> +	      (const_int 0)))]

Am I correctly interpreting the last line of each hunk as telling the gcc core
that these patterns are valid only for functions with zero arguments? If so,
these are OK. But defining call and call_value patterns that are valid for all
functions would definitely violate the VARM, and I would consider that a
serious problem.

But although call and call_value patterns that are valid only for functions
with zero arguments are benign, I think they are unnecessary. calls.c has been
fixed to handle call_pop/call_value_pop only in the mainline back in August
1999 (by you :-), and Bernd said he'll check his fix into the 2.95 branch as
well. So I think the calls.c bug is now a thing of the past and we should no
longer worry about working around it. I think that these call and call_value
patterns are unnecessary, and removing them would reduce the MD clutter and
make it better describe the reality of the VAX architecture. But if you insist
on keeping them, I won't object, as long as they are explicitly restricted (in
the MD, not in calls.c or anywhere else) to zero-argument functions only.

--
Michael Sokolov
Public Service Agent
International Engineering and Science Task Force

1351 VINE AVE APT 27		Phone: +1-714-738-5409
FULLERTON CA 92833-4291 USA	(home office)

E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP)

             reply	other threads:[~2000-12-21 21:53 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-12-21 21:53 Michael Sokolov [this message]
  -- strict thread matches above, loose matches on Subject: below --
2000-12-19 23:51 Michael Sokolov
     [not found] <no.id>
2000-12-19 21:48 ` John David Anglin
2000-12-21 14:32   ` John David Anglin
2000-12-19 21:22 John David Anglin
2000-12-19 18:40 Michael Sokolov
2000-12-14 17:22 John David Anglin
2000-12-14 12:44 Michael Sokolov
2000-12-19 18:01 ` Marc Espie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0012220550.AA02184@ivan.Harhan.ORG \
    --to=msokolov@ivan.harhan.org \
    --cc=gcc@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).