Vladimir Makarov writes:
> On 2015-07-05 7:11 AM, Ajit Kumar Agarwal wrote:
> > All:
> >
> > I am wondering allocation of hot data structure closer to the top of the
> > stack increases
> the performance of the application.
> > The data structure are identified as hot and cold data structure and
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
Steve Ellcey writes:
> On Tue, 2015-09-01 at 10:13 +0200, Georg-Johann Lay wrote:
>
> >
> > I'd have a look at what BEs are using non-default target_gtfiles.
> >
> > Johann
>
> There are a few BEs that add a .c file to target_gtfiles, but no
> platforms that add a .h file to target_gtfiles. I d
H.J. Lu writes:
> On Thu, Sep 3, 2015 at 10:37 AM, H.J. Lu wrote:
> > The interrupt and exception handlers are called by x86 processors. X86
> > hardware puts information on stack and calls the handler. The
> > requirements are
> >
> > 1. Both interrupt and exception handlers must use the 'IRET
H.J. Lu writes:
> On Tue, Sep 15, 2015 at 2:45 PM, Matthew Fortune
> wrote:
> > H.J. Lu writes:
> >> On Thu, Sep 3, 2015 at 10:37 AM, H.J. Lu wrote:
> >> > The interrupt and exception handlers are called by x86 processors. X86
> >> > hardware pu
Jeff Law writes:
> On 01/19/2016 04:59 AM, Woon yung Liu wrote:
> >
> > In my current attempt at adding support for the TI mode, the MMI
> > definitions are added into a MD file for the R5900 and some functions
> > (i.e. mips_output_move) were modified to allow certain moves for the
> > TI mode of
Andreas Arnez writes:
> 6 Summary of Open Questions
> ===
>
> 1. Out of the standard interpretations discussed under "options"
> (section 4) above, which do we want to settle on? Or is the
> "preferred" interpretation missing from that list?
> 2. Should piec
Sorry for the slow response...
Andreas Arnez writes:
> On Mon, Jan 25 2016, Matthew Fortune wrote:
>
> > My dwarf knowledge is not brilliant but I have had to recently
> > consider it for MIPS floating point ABI changes aka FPXX and friends.
> > I don't know exact
Woon yung Liu writes:
> Hi all,
>
> Thank you all for the help so far. This is probably the final part of my
> efforts to complete support for the R5900 within GCC, but I need help
> this time because the existing homebrew GCC version has no support for
> this (despite what its README file says).
Hi Maciej,
Thanks for the update. I've read through the whole proposal again and
it looks good. I'd like to discuss legacy objects a bit more though...
Maciej Rozycki writes:
> 3.4 Relocatable Object Generation
>
> Tools that produce relocatable objects such as the assembler shall
> always p
Woon yung Liu writes:
> On Wednesday, June 1, 2016 5:45 AM, Richard Henderson
> wrote:
> > This is almost always incorrect, and certainly before reload.
> > You need to use gen_lowpart. There are examples in the code
>
> > fragments that I sent the other week.
>
> The problem is that gen_lowpa
Heiher writes:
> Looks the return value of TestNewA is passed on $f0/$f2 from disassembly
> code. I don't known why the return value of TestNewB is passed on
> $v0/$v1? a bug?
I believe this is an area where GNU strays from the N64 ABI definition but
is defacto standard. TestA is a struct of two
Andrew Pinski writes:
> On Sat, Feb 15, 2014 at 12:16 AM, Matthew Fortune
> wrote:
> >> On Fri, Feb 14, 2014 at 2:17 AM, Matthew Fortune
> >> wrote:
> >> > MIPS is currently evaluating the benefit of using SIMD registers to pass
> >> vector data by
Maciej Rozycki writes:
> I'm back to this effort now, thanks for patience.
Likewise, this thread got buried in email. At the risk of further delaying
this work I do still have issues with the design.
> > > 3.4 Relocatable Object Generation
> > >
> > > Tools that produce relocatable objects suc
Hi Joshua,
I know very little about this area but I'll try and offer some advice anyway...
> On 07/05/2014 23:43, Joshua Kinard wrote:
> > Hi,
> >
> > I filed PR61538 about two weeks ago, regarding gcc-4.8.x and up not
> > compiling a g++/pthreads-linked app correctly on SGI R1x000-based systems
etail for a little
while.
Matthew
> -Original Message-
> From: Joshua Kinard [mailto:ku...@gentoo.org]
> Sent: 28 July 2014 10:40
> To: Matthew Fortune; gcc@gcc.gnu.org
> Subject: Re: Help w/ PR61538?
>
> On 07/28/2014 04:41, Matthew Fortune wrote:
> > Hi Joshua,
Jeff Law writes:
> On 07/22/14 06:56, Richard Sandiford wrote:
> > I'll need to step down as MIPS maintainer this weekend in order to
> avoid
> > a possible conflict of interest with a new job. SC: please could you
> > appoint some new maintainers to take over?
> We'll get the process started.
>
Eric Christopher writes:
> On Tue, Jul 29, 2014 at 5:58 AM, Matthew Fortune
> wrote:
> > Jeff Law writes:
> >> On 07/22/14 06:56, Richard Sandiford wrote:
> >> > I'll need to step down as MIPS maintainer this weekend in order to
> >> avoid
> &
We are currently working on the implementation of MSA (SIMD) for MIPS
and are implementing vector interleave instructions which have a
combination of vec_select and vec_concat operators in their patterns.
The selectors for the vec_select operators depend on the vector mode
so to avoid writing multi
Thanks to all.
Matthew
> -Original Message-
> From: Eric Christopher [mailto:echri...@gmail.com]
> Sent: 26 September 2014 21:07
> To: Jeff Law
> Cc: Moore, Catherine; Matthew Fortune; GCC
> Subject: Re: MIPS Maintainers
>
> Congratulations guys!
>
> -eri
Hi,
I'm working on MIPS SIMD support for MSA. Can anyone point me towards
information about the need for an integer mode of equal size to any
supported vector mode?
I.e. if I support V4SImode is there any core GCC requirement that
TImode is also supported?
Any guidance is appreciated. The MIPS p
A
implementation and it did not immediately blow up.
Thanks,
Matthew
> -Original Message-
> From: Bingfeng Mei [mailto:b...@broadcom.com]
> Sent: 12 December 2014 11:52
> To: Matthew Fortune; gcc@gcc.gnu.org
> Subject: RE: Vector modes and the corresponding width integer mod
> Does this cover OS specific areas in the gcc/config.gcc file? For
> example:
>
> https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01214.html
I can’t answer authoritatively but I would expect it does include
OS specific areas of config files. However, as an arch port maintainer
I would be wary of
> On 1/8/2015 9:01 AM, Eric Botcazou wrote:
> >> I've worked on a gcc target that was porting an architecture without
> >> hardware interlock support. Basically, you need to emit nop
> >> operations to avoid possible hw conflicts. At the moment, this was
> >> done by patching the gcc scheduler to d
> On Mon, 12 Jan 2015, Steve Ellcey wrote:
>
> > MULTILIB_OSDIRNAMES += mips32r2=mipsr2/lib MULTILIB_OSDIRNAMES +=
> > .=mipsr2/lib
> >
> > I don't think the first one would work because -mips32r2 is the
> > default architecture and is not explicitly listed in MULTILIB_OPTIONS
> > and I don't thin
Yury Gribov writes:
> On 01/29/2015 08:32 PM, Richard Henderson wrote:
> > On 01/29/2015 02:08 AM, Paul Shortis wrote:
> >> I've ported GCC to a small 16 bit CPU that has single bit shifts. So
> >> I've handled variable / multi-bit shifts using a mix of inline shifts
> >> and calls to assembler su
Steve Ellcey writes:
> Or one could change convert_mult_to_fma to add a check if fma is fused
> vs. non-fused in addition to the check for the flag_fp_contract_mode
> in order to decide whether to convert expressions into an fma and then
> define fma instructions in the md file.
I was about to sa
Conrad S writes:
> On 9 March 2015 at 23:08, Jonathan Wakely wrote:
> >> How did this get into the mirror list?
> >
> > Because they said they would provide mirrors:
> > https://gcc.gnu.org/ml/gcc/2014-06/msg00251.html
> > https://gcc.gnu.org/ml/gcc/2014-07/msg00156.html
>
> Upon closer inspecti
Wilco Dijkstra writes:
> While investigating why the IRA preferencing algorithm often chooses
> incorrect preferences from the costs, I noticed this thread:
> https://gcc.gnu.org/ml/gcc/2011-05/msg00186.html
>
> I am seeing the exact same issue on AArch64 - during the final
> preference selection
Hi Vladimir,
I'm working on PR target/78660 which is looking like a latent LRA bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660
I believe the problem is in the same area as a bug was fixed in 2015:
https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02165.html
Eric pointed out that the new is
Vladimir Makarov writes:
> On 01/16/2017 10:47 AM, Matthew Fortune wrote:
> > Hi Vladimir,
> >
> > I'm working on PR target/78660 which is looking like a latent LRA bug.
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660
> >
> > I believe
Eric Botcazou writes:
> > I'll run testing for at least x86_64, MIPS and another
> > WORD_REGISTER_OPERATIONS target and try to get this committed in the
> > next couple of days so it can get into everyone's testing well before
> release.
>
> No issues found on SPARC.
Thanks Eric.
I'm still boo
Matthew Fortune writes:
...
> Pseudo 300 is assigned to memory and then LRA produces a simple DImode
> load from the assigned stack slot. The only instruction to set pseudo
> 300 is:
>
> (insn 247 212 389 3 (set (reg:SI 300)
> (ne:SI (subreg/s/u:SI (reg/v:D
Eric Botcazou writes:
> > However in lra-constraints.c:simplify_operand_subreg it quite happily
> > performs a reload using the outer mode in this case and only drops
> > down to the inner mode if the outer mode reload would be slower than
> the inner.
> >
> > Presumably this is safe for non WORD_
Hi all,
I've copied you as you have each made some significant change to a function
in LRA which I guess makes you de-facto experts.
I've spent a while researching the history of simplify_operand_subreg and
in particular the behaviour for subregs of memory. For my sake if no-one
else here is a
Eric Botcazou writes:
> > (r243782 git:856bd6f)
> > This is another case of multiple changes where some were not critical
> > and overall there is a dangerous one here I believe. The primary aim
> > of this change is to reload the address before reloading the inner
> > subreg. This appears to be
Segher Boessenkool writes:
> On Thu, Feb 23, 2017 at 04:27:26PM +, Toma Tabacu wrote:
> > > This happens when you have inserted code ending in a jump on an
> edge.
> > > This then will need updating of the CFG, and this code does not know
> > > how to do that.
> >
> > Would the following be an
comp writes:
> Hi all,
> I recently have a problem with LRA.
> 1 The Bug use case
> int a=10;
> float c=2.0,d;
> main()
> {
> float b;
> *(int*)&b=a;
> d=b+c;
> }
>
> 2 The problem description
> In the pass LRA, curr_insn_transform () deal with the addition statement d =
Richard Biener writes:
> On Mon, Jul 31, 2017 at 7:08 PM, Andrew Haley wrote:
> > On 31/07/17 17:12, Oleg Endo wrote:
> >> On Mon, 2017-07-31 at 15:25 +0200, Georg-Johann Lay wrote:
> >>> Around 2010, someone who used a code snipped that I published in a
> >>> wiki, reported that the code didn't
Jeff Law writes:
> On 08/30/2017 06:52 AM, Richard Biener wrote:
> > On Wed, Aug 30, 2017 at 11:53 AM, Michael Clark
> > wrote:
> >>
> >>> On 30 Aug 2017, at 9:43 PM, Michael Clark wrote:
> >>>
> > diff --git a/gcc/simplify-rtx.c b/gcc/simplify-rtx.c
> > index ce632ae..25dd70f 100644
>
Hi Maciej,
Slow thread, sorry for dragging it out further...
Maciej Rozycki writes:
> On Fri, 11 Nov 2016, Matthew Fortune wrote:
>
> > This means that a user consciously creating an object that 'needs'
> ieee
> > compliance via use of -fieee=strict or -mi
Hi,
I've been investigating some quirks of register allocation when handling
some inline asm. The behaviour is non-intuitive but I am not sure if it
is a bug or not. This is back on GCC 6 so I'm still reviewing to see if
anything changed in this area since then.
The inline asm in question is:
in
Hi Catherine,
Thank-you for all the advice and guidance while we have been co-maintaining
the MIPS backend; it's been a pleasure.
Thanks,
Matthew
From: Moore, Catherine [mailto:catherine_mo...@mentor.com]
Sent: 25 April 2018 22:52
To: gcc@gcc.gnu.org
Cc: Matthew Fortune
Subject:
Robert Suchanek writes:
> the last 18 months. This announcement has a general introduction at
> the start, so if you have already read it for one of the other tools,
> you can skip down to the information specific to GCC.
Thanks, Robert.
Corresponding technical info for other toolchain compon
Joseph Myers writes:
> On Wed, 2 May 2018, Matthew Fortune wrote:
>
> > qemu
> >
> > http://lists.nongnu.org/archive/html/qemu-devel/2018-05/msg00081.html
>
> That answers one thing I was wondering, by saying you're using the generic
> Linux kernel sy
Palmer Dabbelt writes:
> On Tue, 29 May 2018 11:02:58 PDT (-0700), Jim Wilson wrote:
> > On 05/26/2018 06:04 AM, Sebastian Huber wrote:
> >> Why is the default multilib and a variant identical?
> >
> > This is supposed to be a single multilib, with two names. We use
> > MULTILIB_REUSE to map the
Hi,
> I was wondering if someone would tell me how to pass an option that
> contains slashes into 'make check'?
>
> For example if I want to test a compiler using a simulator and the -O3 option
> I can run:
>
> make check RUNTESTFLAGS="--target_board='mips-sim-mti32/-O3'"
>
> I want to run this
vant for any
architecture that is not 100% orthogonal which is pretty much all and
particularly important for compressed instruction sets.
Regards,
Matthew
--
Matthew Fortune
Leading Software Design Engineer, MIPS processor IP
Imagination Technologies Limited
t: +44 (0)113 242 9814
www.imgtec.com
> -Original Message-
> From: Vladimir Makarov [mailto:vmaka...@redhat.com]
> Sent: 08 September 2013 17:51
> To: Matthew Fortune
> Cc: gcc@gcc.gnu.org; ber...@codesourcery.com
> Subject: Re: mips16 LRA vs reload - Excess reload registers
>
> On 13-08-23 5:26 A
> > My original post was trying to point out an instance where LRA is not
> performing as well as reload. Although I can avoid this for mips16 it may well
> occur in other circumstances but not be as noticeable. Is this something
> worth pursuing?
> >
> Yes, it is worth pursuing. Whatever reload d
> From: Richard Sandiford [mailto:rdsandif...@googlemail.com]
> Matthew Fortune writes:
> > I have been looking at using the FRAME_GROWS_DOWNWARD macro to
> change
> > the layout of a frame such that spill slots end up closer to the stack
> > pointer. This is usefu
. I initially allowed
$frame to be treated as per $sp but that led to an ICE when $frame was
eliminated to $17 and the immediate was out of range.
Have I missed anything that would allow me to support the full immediate range
in all cases?
Regards,
Matthew
Matthew Fortune
Leading Software Desi
> On 10/29/2013 09:43 AM, Matthew Fortune wrote:
> > Hi Richard/Vladimir,
> >
> > I believe I finally understand one of the issues with LRA and mips16 but I
> can't see how to solve it. Take the following instruction:
> >
> > (insn 5 18 6 2 (set (reg:S
> I'll do the patch tomorrow to fix it. The patch should be not big but it will
> need a lot testing.
Thanks Vladimir. The fix appears to be working.
Hi Richard,
I've been trying to determine for some time whether the MIPS backend has
successfully guaranteed that even when compiling with hard-float enabled there
is no floating point code emitted unless you use floating point types.
My most recent reason for looking at this is because I am st
> > My most recent reason for looking at this is because I am starting to
> > understand/look at mips ld.so from glibc and it appears to make such
> > an assumption. I.e. I cannot see it using any specific options to
> > prevent the use of floating point but the path into the dynamic linker
> > for
> Matthew Fortune writes:
> > I'm still interested in how successfully the MIPS backend is managing
> > to avoid floating point but I am also convinced there are bugs in
> > ld.so entry points for MIPS.
>
> It uses the standard mechanism to avoid it, which is ma
MIPS is currently evaluating the benefit of using SIMD registers to pass vector
data by value. It is currently unclear how important it is for vector data to
be passed in SIMD registers. I.e. the need for passing vector data by value in
real world code is not immediately obvious. The performance
> On Fri, Feb 14, 2014 at 2:17 AM, Matthew Fortune
> wrote:
> > MIPS is currently evaluating the benefit of using SIMD registers to pass
> vector data by value. It is currently unclear how important it is for vector
> data
> to be passed in SIMD registers. I.e. the need fo
All,
Imagination Technologies would like to introduce the design of an O32 ABI
extension for MIPS to allow it to be used in conjunction with MIPS FPUs having
64-bit floating-point registers. This is a wide-reaching design that involves
changes to all components of the MIPS toolchain it is being
Richard Sandiford writes
> Matthew Fortune writes:
> > All,
> >
> > Imagination Technologies would like to introduce the design of an O32
> > ABI extension for MIPS to allow it to be used in conjunction with MIPS
> > FPUs having 64-bit floating-point registers. T
Richard Sandiford writes
> >> AIUI the old form never really worked reliably due to things like
> >> newlib's setjmp not preserving the odd-numbered registers, so it
> >> doesn't seem worth keeping around. Also, the old form is identified
> >> by the GNU attribute (4, 4) so it'd be easy for the l
Richard Sandiford writes
> Doug Gilmore writes:
> > On 02/24/2014 10:42 AM, Richard Sandiford wrote:
> >>...
> >>> AIUI the old form never really worked reliably due to things like
> >>> newlib's setjmp not preserving the odd-numbered registers, so it
> >>> doesn't
> seem worth keeping aroun
> Matthew Fortune writes:
> >> >> If we do end up using ELF flags then maybe adding two new
> >> >> EF_MIPS_ABI enums would be better. It's more likely to be trapped
> >> >> by old loaders and avoids eating up those precious remaining bits.
> > Sorry, forgot about that. In that case maybe program headers would be
> > best, like you say. I.e. we could use a combination of GNU attributes
> > and a new program header, with the program header hopefully being more
> > general than for just this case. I suppose this comes back to the
> >
Hi Thomas,
Do you particularly need a switch for this? You could view this as simply
relaxing the ABI requirements of a module, a switch would only serve to enforce
the need for a compatible ABI and error if not. If you build something for a
soft-float ABI and never actually trigger any of the
> Matthew Fortune writes:
> >> > Sorry, forgot about that. In that case maybe program headers would
> >> > be best, like you say. I.e. we could use a combination of GNU
> >> > attributes and a new program header, with the program header
> >> &
Richard Sandiford writes:
> Matthew Fortune writes:
> >> Matthew Fortune writes:
> >> >> > Sorry, forgot about that. In that case maybe program headers
> >> >> > would be best, like you say. I.e. we could use a combination of
> >> >&
Richard Sandiford writes:
> Matthew Fortune writes:
> > Are you're OK with automatically selecting fpxx if no -mfp option, no
> > .module and no .gnu_attribute exists? Such code would currently end up
> > as FP ABI Any even if FP code was present, I don't suppose
Richard Sandiford writes:
> Matthew Fortune writes:
> > Richard Sandiford writes:
> >> Matthew Fortune writes:
> >> > Are you're OK with automatically selecting fpxx if no -mfp option,
> >> > no .module and no .gnu_attribute exists? Such code woul
ady for stage 1.
Let me know if there is any feedback on the updated spec.
I'm afraid the last aspect we discussed is still a point of contention :-) I'm
sure we'll get there though. I've added more comments inline below:
Richard Sandiford writes:
> Matthew Fortune write
Richard Sandiford writes:
> Matthew Fortune writes:
> > The spec on:
> > https://dmz-portal.mips.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinki
> > ng has been updated and attempts to account for all the feedback. Not
> > everything has been possible to simplif
Richard Sandiford writes:
> Matthew Fortune writes:
> > Richard Sandiford writes:
> >> Matthew Fortune writes:
> >> >> I think instead we should have a configuration switch that allows
> >> >> a particular -mfp option to be inserted alongsi
Richard Sandiford writes:
> Matthew Fortune writes:
> >> > With these defaults, the closest supported ABI is used for each
> >> > architecture based on the --with-o32-fp build option. The only one
> >> > I really care about is the middle one as it ma
Richard Sandiford writes:
> Matthew Fortune writes:
> > As it stands I wasn't planning on supporting .module arch= I was just
> > going to add .module fp= and leave it at that. The only thing I need
> > to give assembly code writers absolute control over is the overall
Hi,
I've sent this email to everyone who had opinions about the introduction of
nan-2008 for mips according to the mailing list archives...
The NaN linkage rules introduced with -mnan=2008 enforce a strict rule that all
code be built with either legacy NaN or 2008 NaN. This impacts both static
Joseph Myers writes:
> > 1) There is no way to mark a module as "don't care/not relevant". At a
> > minimum this could be done via inspection of the GNU FP ABI attribute
> > and when its value is 'Any' then NaNs don't matter. Better still would
> > be that modules with floating point only require
Richard Sandiford writes:
> Matthew Fortune writes:
> > Richard Sandiford writes:
> >> Matthew Fortune writes:
> >> > As it stands I wasn't planning on supporting .module arch= I was
> >> > just going to add .module fp= and leave it at that. The
Maciej W. Rozycki writes:
> On Sat, 22 Mar 2014, Richard Sandiford wrote:
>
> > > Thanks Joseph. I guess I'm not really pushing to have don't-care
> > > supported as it would take a lot of effort to determine when code
> > > does and does not care, you rightly point out more cases to deal
> > > w
Richard Sandiford writes:
> Matthew Fortune writes:
> > Maciej W. Rozycki writes:
> >> On Sat, 22 Mar 2014, Richard Sandiford wrote:
> >>
> >> > > Thanks Joseph. I guess I'm not really pushing to have don't-care
> >> > >
Joseph Myers writes:
> On Tue, 25 Mar 2014, Rich Fuhler wrote:
>
> > Hi Richard, we talked about (a.) originally - it was the design of the
> > libraries. Joseph, as I recollect, you raised language issues with
> > requirements for compile-time constant values for NaNs. Would you
> > accept a non
Joseph Myers writes:
> On Tue, 25 Mar 2014, Matthew Fortune wrote:
>
> > Can you envisage any way of us raising a warning/error if INVALID
> > exceptions get enabled in this hybrid NaN world? I believe that is the
> > only major problem area with mixing NaNs. I.e. It s
Hi Richard,
As part of implementing the new O32 FPXX ABI I am making use of the
HARD_REGNO_CALL_PART_CLOBBERED macro to allow odd-numbered floating-point
registers to be considered as 'normally' callee-saved but call clobbered if
they
are being used to hold SImode or SFmode data. The macro is i
Richard Sandiford writes:
> Matthew Fortune writes:
> > Hi Richard,
> >
> > As part of implementing the new O32 FPXX ABI I am making use of the
> > HARD_REGNO_CALL_PART_CLOBBERED macro to allow odd-numbered
> > floating-point registers to be considered as &#x
Richard Sandiford writes:
> Matthew Fortune writes:
> > Richard Sandiford writes:
> >> Matthew Fortune writes:
> >> Maybe some RA heuristics will need tweaking to reflect the extra
> cost
> >> of these registers, but I imagine that's true either w
Actually add Jeff this time...
> -Original Message-
> From: Matthew Fortune
> Sent: 07 April 2014 09:07
> To: 'Richard Sandiford'
> Cc: gcc@gcc.gnu.org
> Subject: RE: HARD_REGNO_CALL_PART_CLOBBERED and regs_invalidated_by_call
>
> Richard Sandiford w
86 matches
Mail list logo
