From: David Edelsohn <dje.gcc@gmail.com>
To: Michael Meissner <meissner@linux.vnet.ibm.com>,
GCC Patches <gcc-patches@gcc.gnu.org>,
Pat Haugen <pthaugen@us.ibm.com>,
Peter Bergner <bergner@vnet.ibm.com>
Subject: Re: [PATCH, rs6000] power8 patches, patch #8, power8 load fusion + misc.
Date: Mon, 24 Jun 2013 19:43:00 -0000 [thread overview]
Message-ID: <CAGWvnymXKf=+dDW669byf6CNyq6+50YKphNEVq5H6JCHt7sf+g@mail.gmail.com> (raw)
In-Reply-To: <20130624163138.GA16330@ibm-tiger.the-meissners.org>
On Mon, Jun 24, 2013 at 12:31 PM, Michael Meissner
<meissner@linux.vnet.ibm.com> wrote:
>> This really should have been a separate patch.
>
> Yes, you are right. I can separate it to be a separate patch if desired. The
> last I checked, there were still problems in moving to use LRA. It would be
> nice if we could get the switch for better testing, rather than continuing to
> use a branch. Right now my focus as been getting the initial power8 changes
> in, so it was added more because it was in the sandbox, I was working from.
We'll continue as is, but this set of patches should have been split
into more pieces with more descriptive ChangeLog entries to ease the
review process.
>
>> + /* 32-bit is not done yet. */
>> + if (TARGET_ELF && !TARGET_POWERPC64)
>> + return 0;
>>
>> What does "32-bit is not done yet." mean? This means PPC32 Linux is
>> not supported but PPC32 AIX is supported?
>
> I don't believe AIX and Linux 64-bit small code model will work with fusion
> loading the GPRs, except in the case where you have more than 64K in the static
> area that the section anchors point to. It would work with the VSX fusion that
> loads a small constant plus doing hte load. I tend to feel that restructuring
> the code to allow more general addresses before reload, and have secondary
> reload, generate the appropriate instructions will work better, but that may
> take a longer period to get correct (I'm starting work on it now).
>
> I hadn't gotten around to to looking at 32-bit ELF/Linux. In theory, 32-bit
> Linux should work well with fusion for non-pic code.
My question is what will break, not what will remain unoptimized. The
comment is not clear and the code addresses only avoids one very
specific target.
>> + if (TARGET_ELF && !TARGET_POWERPC64)
>> + return 0;
>>
>> Please return "true" and "false" from new predicates, not "1" and "0".
>
> Ok, I was just being constant with the existing code.
Some code uses 0/1 and some uses true/false. Newer code uses true/false.
>
>> +
>> + case DImode:
>> + if (TARGET_POWERPC64)
>> + {
>> + mode_name = "long";
>> + load_str = "ld";
>> + }
>> + break;
>>
>> What happens for DImode when not TARGET_POWERPC64? This should be
>> gcc_unreachable()?
>
> There is a gcc_unreachable () at the end of the switch that is reached by
> either an unknown mode (default case), or by DImode on 32-bit. But I can put
> in two separate gcc_unreachable ()'s.
The current implementation seems like a rather obtuse error path. If
PPC32 DImode is not supported, it would be clearer to fail there, as
opposed to the function called with a garbage or illegal mode.
Thanks, David
next prev parent reply other threads:[~2013-06-24 19:43 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-20 20:41 [PATCH, rs6000] power8 patches Michael Meissner
2013-05-20 20:49 ` [PATCH, rs6000] power8 patch #1, infrastructure changes Michael Meissner
2013-05-20 21:34 ` [PATCH, rs6000] power8 patch #1, infrastructure changes (revised patch) Michael Meissner
2013-05-22 3:29 ` David Edelsohn
2013-05-20 23:13 ` [PATCH, rs6000] power8 patches, patch #2, add crypto builtins Michael Meissner
2013-05-22 3:30 ` David Edelsohn
2013-05-23 3:41 ` David Edelsohn
2013-05-23 3:59 ` Michael Meissner
2013-05-25 4:07 ` David Edelsohn
2013-05-30 21:04 ` Michael Meissner
2013-05-21 2:11 ` [PATCH, rs6000] power8 patches Peter Bergner
2013-05-21 15:51 ` [PATCH, rs6000] power8 patches, patch #3, add V2DI vector support Michael Meissner
2013-05-23 16:31 ` David Edelsohn
2013-05-21 23:47 ` [PATCH, rs6000] power8 patches, patch #4, new power8 builtins Michael Meissner
2013-05-25 4:03 ` David Edelsohn
2013-05-30 23:26 ` Michael Meissner
2013-05-31 9:14 ` Segher Boessenkool
2013-05-31 15:11 ` Michael Meissner
2013-06-04 18:49 ` [PATCH, rs6000] power8 patches, patch #4 (revised), " Michael Meissner
2013-06-05 14:28 ` David Edelsohn
2013-06-05 15:50 ` Segher Boessenkool
2013-06-05 16:05 ` Michael Meissner
2013-06-05 20:06 ` Segher Boessenkool
2013-06-05 20:24 ` Michael Meissner
2013-06-05 16:13 ` Michael Meissner
2013-06-05 17:28 ` David Edelsohn
2013-06-06 15:57 ` David Edelsohn
2013-06-06 21:42 ` Michael Meissner
2013-07-15 21:48 ` Michael Meissner
2013-07-20 19:12 ` David Edelsohn
2013-07-23 21:24 ` Michael Meissner
2013-05-21 23:49 ` [PATCH, rs6000] power8 patches, patch #5, new vector tests Michael Meissner
2013-06-06 21:51 ` Michael Meissner
2013-05-22 14:26 ` [PATCH, rs6000] power8 patches, patch #6, direct move & basic quad load/store Michael Meissner
2013-05-29 19:53 ` David Edelsohn
2013-05-29 20:32 ` Michael Meissner
2013-06-10 15:41 ` David Edelsohn
2013-06-10 20:26 ` Michael Meissner
2013-05-22 16:51 ` [PATCH, rs6000] power8 patches, patch #7, quad/byte/half-word atomic instructions Michael Meissner
2013-05-29 20:29 ` David Edelsohn
2013-05-29 20:36 ` Michael Meissner
2013-06-11 23:56 ` Michael Meissner
2013-06-12 21:55 ` David Edelsohn
2013-05-22 20:53 ` [PATCH, rs6000] power8 patches, patch #8, power8 load fusion + misc Michael Meissner
2013-06-18 18:30 ` David Edelsohn
2013-06-24 16:32 ` Michael Meissner
2013-06-24 19:43 ` David Edelsohn [this message]
2013-07-29 18:46 ` [PATCH, rs6000] power8 patches, revised patch #8, power8 load fusion Michael Meissner
2013-07-31 16:00 ` David Edelsohn
2013-11-23 16:48 ` Alan Modra
2013-06-07 19:22 ` [PATCH, rs6000] power8 patches, patch #9, power8 scheduling Pat Haugen
2013-06-19 13:00 ` David Edelsohn
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='CAGWvnymXKf=+dDW669byf6CNyq6+50YKphNEVq5H6JCHt7sf+g@mail.gmail.com' \
--to=dje.gcc@gmail.com \
--cc=bergner@vnet.ibm.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=meissner@linux.vnet.ibm.com \
--cc=pthaugen@us.ibm.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).