public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "rsandifo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/49169] ARM: optimisations strip the Thumb/ARM mode bit off function pointers
Date: Tue, 07 Jun 2011 07:33:00 -0000	[thread overview]
Message-ID: <bug-49169-4-C67roirnka@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-49169-4@http.gcc.gnu.org/bugzilla/>

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49169

rsandifo@gcc.gnu.org <rsandifo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rsandifo at gcc dot gnu.org

--- Comment #4 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> 2011-06-07 07:32:37 UTC ---
(In reply to comment #3)
> Btw, we finally should introduce a target hook for this I think.

Thanks for the patch in comment #2.  How strongly do you feel
about the hook though?  In PR35705, it sounded like a lot of
targets actually need an opt-out for functions, either because
of ISA encoding (ARM, MIPS, SH) or because of function
descriptors (IA-64, PA, PPC).

I notice that ARM and mcore also have optimisation-dependent
FUNCTION_BOUNDARYs.  Arguably (very arguably) that's a bug,
and they should be using align_functions instead.  But if we
make a deliberate decision to honour DECL_ALIGN on functions,
then FUNCTION_BOUNDARY really will be an ABI property.
I'm just worried that the combination of that and the need
to identify exactly which targets should define the hook
might be more hassle than the optimisation is worth.

You said in that bug that masking function addresses isn't
likely to be a common operation, and TBH, I still agree.

Richard


  parent reply	other threads:[~2011-06-07  7:33 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-26  2:23 [Bug rtl-optimization/49169] New: " michael.hope at linaro dot org
2011-05-26  7:59 ` [Bug rtl-optimization/49169] " mikpe at it dot uu.se
2011-05-26  8:22 ` rguenth at gcc dot gnu.org
2011-05-26  8:48 ` rguenth at gcc dot gnu.org
2011-06-07  7:33 ` rsandifo at gcc dot gnu.org [this message]
2011-06-27  9:34 ` rsandifo at gcc dot gnu.org
2011-07-08 15:05 ` ramana at gcc dot gnu.org
2011-09-19  9:00 ` jye2 at gcc dot gnu.org
2012-07-31  1:00 ` ramana 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-49169-4-C67roirnka@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: 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).