-Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Ajit
Kumar Agarwal
Sent: Monday, August 17, 2015 4:03 PM
To: Richard Biener
Cc: Jeff Law; gcc@gcc.gnu.org; Vinod Kathail; Shail Aditya Gupta; Vidhumouli
Hunsigida; Nagaraju Mekala
Subject: RE: vec
On 19 August 2015 at 03:16, Martin Sebor wrote:
> On 08/03/2015 12:35 PM, Joel Sherrill wrote:
>>
>> Hi
>>
>> Just noticed this building the head for arm-rtems4.11. Should
>> the first comparison be eliminated and, maybe, a comment added?
>>
>> ctype_members.cc:216:14: warning: comparison of unsign
We are working on an analysis for identifying the class of an object flow
sensitively for
flow sensitive de-virtualization (i.e. replacing a virtual function call by a
call to the
function of a known class in the hierarchy). This is a regular ipa pass. It
find outs the
class of an object at po
On Wed, Aug 19, 2015 at 7:16 PM, Uday P. Khedker wrote:
>
> We are working on an analysis for identifying the class of an object flow
> sensitively for
> flow sensitive de-virtualization (i.e. replacing a virtual function call by
> a call to the
> function of a known class in the hierarchy). This
Hi all,
This simple patch will tighten the conditions when matching movw and
arm_movt rtx pattern.
Those two patterns will generate the following assembly:
movw w1, #:lower16: dummy + addend
movt w1, #:upper16: dummy + addend
The addend here is optional. However, it should be an 16-bit signed
Andrew Pinski wrote on Wednesday 19 August 2015 04:44 PM:
On Wed, Aug 19, 2015 at 7:16 PM, Uday P. Khedker wrote:
We are working on an analysis for identifying the class of an object flow
sensitively for
flow sensitive de-virtualization (i.e. replacing a virtual function call by
a call to the
On Wed, Aug 19, 2015 at 2:10 PM, Uday P. Khedker wrote:
>
>
> Andrew Pinski wrote on Wednesday 19 August 2015 04:44 PM:
>>
>> On Wed, Aug 19, 2015 at 7:16 PM, Uday P. Khedker
>> wrote:
>>>
>>> We are working on an analysis for identifying the class of an object flow
>>> sensitively for
>>> flow s
If a new option is added, of course it needs documenting in the ld manual
(ld.texinfo).
--
Joseph S. Myers
jos...@codesourcery.com
I am trying to create a new IPA pass to scan the routines being compiled
by GCC and I thought I would put it in after the last IPA pass (comdats)
so I tried to register it with:
opt_pass *p = make_pass_ipa_frame_header_opt (g);
static struct register_pass_info f =
{p, "comdats", 1, P
On Wed, 2015-08-19 at 10:27 -0700, Steve Ellcey wrote:
> I am trying to create a new IPA pass to scan the routines being compiled
> by GCC and I thought I would put it in after the last IPA pass (comdats)
> so I tried to register it with:
>
> opt_pass *p = make_pass_ipa_frame_header_opt (g);
>
On Wed, 2015-08-19 at 13:40 -0400, David Malcolm wrote:
> Is your pass of the correct type? (presumably IPA_PASS). I've run into
> this a few times with custom passes (which seems to be a "gotcha");
> position_pass can fail here:
>
> /* Check if the current pass is of the same type as the
When compiling ARM/thumb with -Os for size, I've seen some cases where GCC
generates unnecessary move instructions.
It seems sometimes that there are some possibility to improve the use from
2-operand into 3-operand instructions.
Some patterns I see is:
Generated code Case 1:
I've seen this on other targets too, sometimes so bad I write a quick
target-specific "stupid move optimizer" pass to clean it up.
A generic pass would be much harder, but very useful.
DJ Delorie writes:
> I've seen this on other targets too, sometimes so bad I write a quick
> target-specific "stupid move optimizer" pass to clean it up.
>
> A generic pass would be much harder, but very useful.
Robert (on cc) is currently attempting some improvements to the regrename
pass to tr
On 08/19/2015 02:38 PM, DJ Delorie wrote:
I've seen this on other targets too, sometimes so bad I write a quick
target-specific "stupid move optimizer" pass to clean it up.
A generic pass would be much harder, but very useful.
More important is to determine *why* we're getting these patterns. I
(Resending due to email glitch)
Thanks again for your comments.
On 8/18/2015 2:23 AM, Segher Boessenkool wrote:
On Mon, Aug 17, 2015 at 09:55:48PM -0700, David Wohlferd wrote:
On systems where an underscore is normally prepended to the name
of a C
-function or variable, this feature allows
On Wed, Aug 19, 2015 at 02:08:16PM -0700, David Wohlferd wrote:
> >>My intent here is to break this clearly into two @subsubheadings:
> >>'Assembler names for data' and 'Assembler names for functions'. Since
> >>data is the first section, I removed the word 'function' here.
> >I missed that, sorry.
(It appears I accidentally dropped the mailing list)
Hi,
> On 08/19/2015 02:38 PM, DJ Delorie wrote:
> > I've seen this on other targets too, sometimes so bad I write a quick
> > target-specific "stupid move optimizer" pass to clean it up.
> >
> > A generic pass would be much harder, but very use
Snapshot gcc-4.9-20150819 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20150819/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.9 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
[snip]
how about replacing the existing
text ("It does not make sense to use this feature with a non-static
local variable since such variables do not have assembler names.") with
"Do not use this feature with a non-static local variable." or maybe "It
is not supported to use this feature with a
20 matches
Mail list logo
