public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "olegendo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/64305] New: [SH] Add support for fschg insn and 64 bit FP moves Date: Sun, 14 Dec 2014 13:56:00 -0000 [thread overview] Message-ID: <bug-64305-4@http.gcc.gnu.org/bugzilla/> (raw) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64305 Bug ID: 64305 Summary: [SH] Add support for fschg insn and 64 bit FP moves Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: olegendo at gcc dot gnu.org Target: sh*-*-* Currently, 64 bit FP moves are utilized only for handling DFmode types when the option -mfmovd (and is specified. The way it's done right now works only on SH4A and SH2A, since FPSCR.SZ is tied to FPSCR.PR. On SH4A and SH2A loading DFmode types from memory using 64 bit FP moves (FPSCR.SZ = 1) performs little/big endian swapping if FPSCR.PR = 1. If FPSCR.PR = 0 the two 32 bit halves are loaded as a pair of SFmode values in big endian order. On SH4 64 bit FP moves are only defined for FPSCR.SZ = 1 and FPSCR.PR = 0, which allows loading of DFmode values in big endian ordering only. 64 bit FP moves can be used for accessing DFmode types in memory on SH4 little endian, but the memory layout for those values would be have to be half little-endian half big-endian. This could be realized with some optional -m setting. 64 bit FP moves for (FPSCR.SZ = 1 FPSCR.PR = 0) can be utilized on SH4, SH4A, SH2A for doing SFmode vector loads, since the order of the vector elements is endian invariant. E.g. the following typedef float v4sf __attribute__ ((vector_size (16))); float test (v4sf* x) { return (*x)[0]; } compiles to rts fmov.s @r4,fr0 regardless of the endian mode. What is currently lacking to realize the above is FPSCR.SZ mode switching. Notice that the 'fschg' insn is only valid when FPSCR.PR = 0 on all FPU enabled cores (SH2A, SH4, SH4A). Thus FPSCR.SZ mode switching depends on FPSCR.PR mode switching to some extent. On SH2A and SH4 FPSCR.PR mode switching is done using sts-modify-lds sequences of FPSCR, since there is no fpchg insn. If SZ and PR mode switching is done independently, multiple FPSCR mode switches might need combining for better efficiency. In some cases FP register-to-register moves and loads/stores of adjacent SFmode values can also be done via 64 bit FP moves. Recently a new pass 'pass_sched_fusion' has been added, which tries to fuse such adjacent loads/stores. On SH 64 bit FP moves can only operate on even register numbers, thus fusing loads/stores has an impact on the register allocation. The new pass 'pass_sched_fusion' on the other hand is done before peephole2, which is after register allocation/reload and thus will probably not be that useful on SH. Whether using a 64 bit FP move (either for SFmode vectors, DFmode types or fused SFmode access) will be beneficial or not depends on the surrounding code and the number of FPSCR.SZ mode switches that need to be inserted. If insns can't be grouped to minimize mode switches (see PR 64299) it might be better to split 64 bit FP moves into 32 bit FP moves.
next reply other threads:[~2014-12-14 13:56 UTC|newest] Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-12-14 13:56 olegendo at gcc dot gnu.org [this message] 2014-12-14 15:38 ` [Bug target/64305] " olegendo at gcc dot gnu.org
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=bug-64305-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@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: linkBe 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).