public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <law@redhat.com>
To: gcc-patches@gcc.gnu.org, richard.sandiford@arm.com
Subject: Re: Use target-insns.def for calls
Date: Mon, 24 Aug 2015 17:54:00 -0000	[thread overview]
Message-ID: <55DB5732.4020502@redhat.com> (raw)
In-Reply-To: <87fv387spi.fsf@e105548-lin.cambridge.arm.com>

On 08/24/2015 06:54 AM, Richard Sandiford wrote:
> calls.c had support for sibcall_pop and sibcall_value_pop, but no port
> defines those patterns and the code looks inconsistent with the corresponding
> call_pop vs. call code.  I've therefore dropped it rather than add untested
> entries to the .def file.  (The patterns were also undocumented.)
Sounds reasonable.  Interestingly enough, there are certainly cases 
where a popping sibcall would be helpful, but if we're not using them, 
then dropping seems best.


>
> The calls.c code was a bit confusing in that it tested whether
> sibcall and sibcall_value are available when ECF_SIBCALL is set.
> By this point the decision about whether to use a sibcall has already
> been made, and we set SIBLING_CALL_P directly from ECF_SIBCALL, so we
> would silently generate wrong code if we emitted a normal call instead.
> The patch therefore drops the have_* checks and calls the generator
> regardless.  The generator will assert that the pattern is available.
>
> Tested on x86_64-linux-gnu.  Also tested by building one target per cpu
> directory and checking that there were no changes in the assembly output
> for gcc.dg, g++.dg and gcc.c-torture.  OK to install?
>
> Thanks,
> Richard
>
> gcc/
> 	* genflags.c (gen_macro): Delete.
> 	(gen_proto): Don't create GEN.*CALL.* macros.
> 	* gensupport.h (get_file_location): Declare.
> 	* gensupport.c (rtx_locs): New variable.
> 	(read_md_rtx): Record rtx locations.
> 	(get_file_location): New function.
> 	* target-insns.def (call, call_pop, call_value, call_value_pop)
> 	(sibcall, sibcall_value): New patterns.
> 	* gentarget-def.c (parse_argument): New function.
> 	(def_target_insn): Use it.  Handle optional operands.  Raise an
> 	error if an .md pattern has the wrong number of operands for the
> 	pattern name.  Remove the names of unused operands from the prototype.
> 	* builtins.c (expand_builtin_apply): Use targetm functions
> 	instead of HAVE_call_value and GEN_CALL_VALUE.
> 	* calls.c (emit_call_1): Likewise.  Remove support for sibcall_pop
> 	and sibcall_value_pop.
> 	* config/aarch64/aarch64.md (untyped_call): Use gen_call instead
> 	of GEN_CALL.
> 	* config/alpha/alpha.md (untyped_call): Likewise.
> 	* config/iq2000/iq2000.md (untyped_call): Likewise.
> 	* config/m68k/m68k.md (untyped_call): Likewise.
> 	* config/mips/mips.md (untyped_call): Likewise.
> 	* config/pa/pa.md (untyped_call): Likewise.
> 	* config/rs6000/rs6000.md (untyped_call): Likewise.
> 	* config/sparc/sparc.md (untyped_call): Likewise.
> 	* config/tilegx/tilegx.md (untyped_call): Likewise.
> 	* config/tilepro/tilepro.md (untyped_call): Likewise.
> 	* config/visium/visium.md (untyped_call): Likewise.
> 	* config/alpha/alpha.c (alpha_emit_xfloating_libcall): Use
> 	gen_call_value instead of GEN_CALL_VALUE.
> 	* config/arm/arm.md (untyped_call): Likewise.
> 	* config/cr16/cr16.c (cr16_function_arg): Remove reference to
> 	GEN_CALL.
OK

Thanks,
Jeff


      reply	other threads:[~2015-08-24 17:41 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-24 12:55 Richard Sandiford
2015-08-24 17:54 ` Jeff Law [this message]

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=55DB5732.4020502@redhat.com \
    --to=law@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=richard.sandiford@arm.com \
    /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).