public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Richard Henderson <rth@redhat.com>,
	Jason Merrill <jason@redhat.com>,
	       Cary Coutant <ccoutant@google.com>
Cc: gcc-patches@gcc.gnu.org, Roland McGrath <roland@hack.frob.com>,
	       Jan Kratochvil <jkratoch@redhat.com>,
	Tom Tromey <tromey@redhat.com>,
	       Mark Wielaard <mjw@redhat.com>
Subject: Typed DWARF stack and convert to untyped
Date: Thu, 09 Jun 2011 15:47:00 -0000	[thread overview]
Message-ID: <20110609145319.GO17079@tyan-ft48-01.lab.bos.redhat.com> (raw)
In-Reply-To: <20110325113237.GY18914@tyan-ft48-01.lab.bos.redhat.com>

Hi!

On Fri, Mar 25, 2011 at 12:32:37PM +0100, Jakub Jelinek wrote:
> This patch on top of
> http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01224.html
> and
> http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01723.html
> implements parts of Cary's typed DWARF stack proposal:
> http://www.dwarfstd.org/doc/040408.1.html

GCC currently doesn't fully adhere to the above SPEC (even with the
agreed on slight changes for some binary ops), in particular to the
binary ops operand need to have the same type.

Currently once a value on the stack is typed, the typedness
propagates forever through unary/binary ops (the only exception
are comparisons that push untyped result even for typed operands).

I'd like to propose convert to untyped operation, e.g.
DW_OP_GNU_convert <0> could do it (and maybe DW_OP_GNU_reinterpret <0>),
these would convert to an integral value of the same size as DWARF
address and make it untyped.  As DW_OP_GNU_convert operand is
uleb128 DIE offset within current CU, offset 0 certainly won't
contain any DIEs, because it is the first byte of the CU header.

Without this, currently GCC will sometimes end up with one
operand typed, another untyped.  While it is solvable even just on
the GCC side (mem_loc_descriptor would need to track whether the
TOS of the expression it returned is typed, untyped (or uncertain,
e.g. for DW_OP_GNU_parameter_ref), as that would be determined
by the matching DW_AT_GNU_call_site_value, and when e.g. for binary
operation one argument is determined as typed, the other argument
would need to be converted to typed as well if untyped, and any
uncertain operand of a binary op or unary that cares about the
sign would need to be converted to typed), I think it would
generate unnecessarily bloated code, as e.g. after a float is
converted to int or other small integer suddenly all further
additions etc. would need to convert constants etc. to typed values
(or use DW_OP_const_type).  With an convert to untyped operation,
mem_loc_descriptor could just ensure that for integral modes <=
DWARF_ADDR_SIZE the result is untyped (current gcc code sort of
assumes that) and only when a larger mode is needed or non-integral,
it would be typed, and when sign matters for operation of integral small
modes, it could just temporarily convert to typed and back.

Does this sound reasonable, or is it too ugly?

	Jakub

  parent reply	other threads:[~2011-06-09 14:53 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-25 11:33 [RFC PATCH] Typed DWARF stack Jakub Jelinek
2011-03-25 16:48 ` Roland McGrath
2011-03-28  9:25   ` Jakub Jelinek
2011-03-25 17:51 ` Cary Coutant
2011-04-16  9:28 ` [PATCH] " Jakub Jelinek
2011-04-29 21:01   ` Jason Merrill
2011-05-03 13:34   ` H.J. Lu
2011-05-08 18:57     ` H.J. Lu
2011-05-04 18:22 ` [RFC PATCH] " Tom Tromey
2011-05-04 18:30   ` Cary Coutant
2011-05-04 18:37   ` Jakub Jelinek
2011-05-04 20:27     ` Tom Tromey
2011-05-12 21:16       ` Tom Tromey
2011-05-12 21:37         ` Tom Tromey
2011-06-09 15:47 ` Jakub Jelinek [this message]
2011-06-09 18:34   ` Typed DWARF stack and convert to untyped Jakub Jelinek
2011-06-13 15:34   ` Tom Tromey

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=20110609145319.GO17079@tyan-ft48-01.lab.bos.redhat.com \
    --to=jakub@redhat.com \
    --cc=ccoutant@google.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jason@redhat.com \
    --cc=jkratoch@redhat.com \
    --cc=mjw@redhat.com \
    --cc=roland@hack.frob.com \
    --cc=rth@redhat.com \
    --cc=tromey@redhat.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).