public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Zack Weinberg <zack@codesourcery.com>
To: Florian Weimer <fw@deneb.enyo.de>
Cc: kenner@vlsi1.ultra.nyu.edu (Richard Kenner),  gcc-patches@gcc.gnu.org
Subject: Re: [patch] for PR 18040
Date: Tue, 19 Oct 2004 22:40:00 -0000	[thread overview]
Message-ID: <87ekjuqqs9.fsf@codesourcery.com> (raw)
In-Reply-To: <87vfd85hq8.fsf@deneb.enyo.de> (Florian Weimer's message of "Mon, 18 Oct 2004 14:33:03 +0200")

Florian Weimer <fw@deneb.enyo.de> writes:

> Unfortunately, var doesn't have to be addressable.  Consider the
> following example:
>
> with Ada.Unchecked_Conversion;
>
> procedure Bar is
>
>    type T is mod 2**4;
>    type Foo is record
>       A, B : T;
>    end record;
>    pragma Pack (Foo);
>    for Foo'Size use 8;
>
>    type U is mod 2**2;
>    type Baz is record
>       A, B : U;
>    end record;
>    pragma Pack (Baz);
>    for Baz'Size use 4;
>
>    Var1 : Foo;
>    pragma Import (Ada, Var1);
>
>    Var2 : U;
>    pragma Import (Ada, Var2);
>
>    function Convert is new Ada.Unchecked_Conversion (T, Baz);
>
> begin
>    Var2 := Convert (Var1.B).B;
> end Bar;

This is the case that I suggested could be handled by pushing the type
conversion to the top level of the nest, as-if the programmer had
written

with Ada.Unchecked_Conversion;

procedure Bar is

   type T is mod 2**4;
   type U is mod 2**2;

   type Foo is record
      A, B : T;
   end record;
   pragma Pack (Foo);
   for Foo'Size use 8;  -- N.B. I am assuming this number is in bits.

   type Quux is record
     AA, AB, BA, BB : U;
   end record;
   pragma Pack (Quux);
   for Quux'Size use 8;

   Var1 : Foo;
   pragma Import (Ada, Var1);
   
   Var2 : U;
   pragma Import (Ada, Var2);

   function Convert is new Ada.Unchecked_Conversion (Foo, Quux);

begin
   Var2 := Convert(Var1).BB;
end;

or, in C,

struct Foo __attribute__ ((packed)) {
  unsigned char A : 4;
  unsigned char B : 4;
};

struct Quux __attribute__ ((packed)) {
  unsigned char AA : 2;
  unsigned char AB : 2;
  unsigned char BA : 2;
  unsigned char BB : 2;
};

extern struct Foo var1;
extern char var2;  /* original type not representable in C */

void bar(void)
{
  struct Quux *q = (struct Quux *) &var1;

  var2.value = q->BB;
}

This transformation, however, has the problem that Kenner pointed out,
of possibly requiring a quadratic number of type-synthesis operations
at compile time.

> For the example above, all versions of GNAT I've tested (GNAT 3.15p,
> GCC 3.4, mainline) generate somewhat questionable code which involves
> bit operations on registers that are only partly defined (the
> undefined bits are subsequently masked away, though).

I'll add that I get much better code out of GNAT after the
transformation I demonstrated.  With GCC 3.3.5, before:

        movzbl  var1, %edx
        andb    $-16, %al
        shrb    $4, %dl
        orb     %dl, %al
        shrb    $2, %al
        andb    $3, %al
        movb    %al, var2
        ret

and after:

        movzbl  var1, %eax
        shrb    $6, %al
        movb    %al, var2
        ret

The C version also produces this improved code.

>> The only catch is that alias analysis must understand that rp aliases
>> var.  This may require some adjustment to GNAT's alias set logic.
>
> I'm not sure if this is actually required by the language, but
> real-world code probably needs this.

Agree.

zw

  parent reply	other threads:[~2004-10-19 22:36 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-17 22:30 Richard Kenner
2004-10-17 22:36 ` Andrew Pinski
2004-10-17 23:41 ` Zack Weinberg
2004-10-18 13:13   ` Florian Weimer
2004-10-18 17:24     ` Jason Merrill
2004-10-18 17:37       ` Florian Weimer
2004-10-18 18:02         ` Jason Merrill
2004-10-19 22:40     ` Zack Weinberg [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-10-20 13:27 Richard Kenner
2004-10-20  0:25 Richard Kenner
2004-10-19 23:26 Richard Kenner
2004-10-19 23:22 Richard Kenner
2004-10-19 23:03 Richard Kenner
2004-10-19 23:13 ` Jason Merrill
2004-10-19 22:48 Richard Kenner
2004-10-19 23:01 ` Jason Merrill
2004-10-19 23:07 ` Zack Weinberg
2004-10-18 17:48 Richard Kenner
2004-10-18 15:42 Richard Kenner
2004-10-18 14:52 Richard Kenner
2004-10-18 15:20 ` Daniel Berlin
2004-10-18 14:38 Richard Kenner
2004-10-18 14:24 Richard Kenner
2004-10-19 22:50 ` Zack Weinberg
2004-10-18 14:22 Richard Kenner
2004-10-19 22:47 ` Zack Weinberg
2004-10-18  3:12 Richard Kenner
2004-10-18  4:02 ` Zack Weinberg
2004-10-18  4:26   ` Daniel Berlin
2004-10-18  2:46 Richard Kenner
2004-10-18  2:38 Richard Kenner
2004-10-18  3:14 ` Zack Weinberg
2004-10-18  2:35 Richard Kenner
2004-10-18  2:51 ` Zack Weinberg
2004-10-17 23:06 Richard Kenner
2004-10-17 23:45 ` Zack Weinberg
2004-10-18  0:23   ` Zack Weinberg
2004-10-17 21:24 Richard Kenner
2004-10-17 21:43 ` Zack Weinberg
2004-10-17 21:18 Richard Kenner
2004-10-17 21:26 ` Zack Weinberg
2004-10-17 21:04 Richard Kenner
2004-10-17 21:10 ` Zack Weinberg
2004-10-19 21:36   ` Richard Henderson
2004-10-19 22:19     ` Daniel Berlin
2004-10-20  7:03       ` Jason Merrill
2004-10-19 22:51     ` Zack Weinberg
2004-10-20  0:02       ` Richard Henderson
2004-10-17 20:25 Richard Kenner
2004-10-17 20:47 ` Daniel Berlin
2004-10-17 20:17 Richard Kenner
2004-10-17 20:25 ` Daniel Berlin
2004-10-17 19:46 Richard Kenner
2004-10-17 19:46 ` Daniel Berlin
2004-10-17 19:48 ` Zdenek Dvorak
2004-10-17 20:01   ` Daniel Berlin
2004-10-17 19:28 Zdenek Dvorak
2004-10-19 21:36 ` Richard Henderson
2004-10-19 22:03   ` Zdenek Dvorak
2004-10-19 22:04     ` Andrew Pinski
2004-10-19 22:06       ` Zdenek Dvorak

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=87ekjuqqs9.fsf@codesourcery.com \
    --to=zack@codesourcery.com \
    --cc=fw@deneb.enyo.de \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=kenner@vlsi1.ultra.nyu.edu \
    /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).