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
prev parent 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).