public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Paul Edwards" <mutazilah@gmail.com>
To: <gcc@gcc.gnu.org>, "Richard Biener" <richard.guenther@gmail.com>
Subject: Re: negative indexes
Date: Sun, 14 Mar 2021 22:48:21 +1100	[thread overview]
Message-ID: <44C9A7E5AF59490B8F860471B8E4ECF7@DESKTOP0OKG1VA> (raw)

Basically the rule (which can be configurable if
different machines behave differently) should be
(for pure 32-bit code generation):


1. If your machine treats indexes as signed values:

a) If the requested index is between -2 GiB and
+ 2 GiB, fine, do it.

b) If the requested index is greater than 2 GiB,
you will need to do an addition instead.


2. If your machine treats indexes as as unsigned values:

a) If the requested index is less than 0, do a subtraction
instead.

b) Any non-negative value can be used as an index.


Although that logic should only be applied if you have
an environment where you don't get saved by address
wraparound. If you have a machine that for any reason
enforces an attempt to index beyond 4 GiB, or below
0 (instead of just letting the address wrap), then the
compiler needs to respect that.

This applies to all environments, not just i370.

BFN. Paul.




-----Original Message----- 
From: Paul Edwards 
Sent: Sunday, March 14, 2021 7:12 PM 
To: gcc@gcc.gnu.org ; Richard Biener 
Subject: Re: negative indexes 

Hi Richard. Thanks for your reply, but if I understand
you correctly, you are saying this fix is for situations
where the size of an integer is different from the size
of a pointer?

That is not my issue. The size is the same. Absolutely
everything is 32-bits in the program (long, int, char *,
void *, code addresses).

However, since I am running as AMODE 64, if someone
attempts to do an index by adding two 32-bit registers
together in a single instruction, that reference will
actually take effect, and go up into the 4 GiB to 8 GiB
region.

Is your answer still applicable (I don't really understand
your answer. :-) ).

Thanks. Paul.




-----Original Message----- 
From: Richard Biener
Sent: Sunday, March 14, 2021 7:05 PM
To: Paul Edwards ; Paul Edwards via Gcc ; gcc@gcc.gnu.org
Subject: Re: negative indexes

On March 14, 2021 6:55:32 AM GMT+01:00, Paul Edwards via Gcc 
<gcc@gcc.gnu.org> wrote:
>If I have code like this:
>
>char foo(char *p)
>{
>    return (p[-1]);
>}
>
>It generates a negative index, like this:
>
>* Function foo code
>         L     2,=F'-1'
>         L     3,0(11)
>         SLR   15,15
>         IC    15,0(2,3)
>* Function foo epilogue
>
>See that (2,3) - that is adding both R2 + R3.
>R3 is a pointer to a location in 4 GiB space.
>R2 is now 0xFFFFFFFF
>
>In 64-bit mode, both of those values are added
>together and there is no address wrap, so it
>accesses memory above the 4 GiB boundary
>(between 4 GiB and 8 GiB to be precise)
>which I don't have access to.
>
>Is there a way of constraining index registers to positive
>values?
>
>I want it to instead generate
>ALR 3,2
>to add these two values together using 32-bit arithmetic,
>causing truncation at 32 bits, then it can do
>IC 15,0(3)
>(ie no index)
>
>I'm using GCC 3.2.3 using the i370 target if it makes a difference.

You are likely missing a fix that sign extends offsets on Pmode!=ptr_mode 
targets. 3.2.3 is really old now ;)

Richard.

>Thanks. Paul. 

             reply	other threads:[~2021-03-14 11:48 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-14 11:48 Paul Edwards [this message]
  -- strict thread matches above, loose matches on Subject: below --
2009-11-24 14:05 i370 port - 3.4.6 to 4.4 upgrade attempt Ulrich Weigand
2009-11-28 15:14 ` i370 port - music/sp - possible generic gcc problem Paul Edwards
2009-11-28 16:03   ` Richard Guenther
2021-03-14  5:55     ` negative indexes Paul Edwards
2021-03-14  8:05       ` Richard Biener
2021-03-14  8:12         ` Paul Edwards
2021-03-14 13:37           ` Richard Biener
     [not found]             ` <755065BE2A0B4B508DD3A262B2A83801@DESKTOP0OKG1VA>
2021-03-15  9:22               ` Richard Biener

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=44C9A7E5AF59490B8F860471B8E4ECF7@DESKTOP0OKG1VA \
    --to=mutazilah@gmail.com \
    --cc=gcc@gcc.gnu.org \
    --cc=richard.guenther@gmail.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).