Re: Function Multiversioning Usability.

On Tue, Aug 16, 2011 at 10:37 PM, Sriraman Tallam wrote: > Hi, > >  I am working on supporting function multi-versioning in GCC and here > is a write-up on its usability. > > Multiversioning Usability > > > For a simple motivating example, > > int > find_popcount(unsigned int

Just what are rtx costs?

I've been working on some patches to make insn_rtx_cost take account of the cost of SET_DESTs as well as SET_SRCs. But I'm slowly beginning to realise that I don't understand what rtx costs are supposed to represent. AIUI the rules have historically been: 1) Registers have zero cost. 2) Con

Re: Function Multiversioning Usability.

The gist of previous discussion is to use function overloading instead of exposing underlying implementation such as builtin_dispatch to the user. This new refined proposal has not changed in that, but is more elaborate on various use cases which has been carefully thought out. Please be specific o

Re: Function Multiversioning Usability.

On Wed, Aug 17, 2011 at 4:52 PM, Xinliang David Li wrote: > The gist of previous discussion is to use function overloading instead > of exposing underlying implementation such as builtin_dispatch to the > user. This new refined proposal has not changed in that, but is more > elaborate on various u

Re: FDO and LTO on ARM

On Thu, Aug 11, 2011 at 09:27:23AM -0700, Xinliang David Li wrote: > > Maybe I have an idea as to why FDO doesn't work so well. Does the > > instrumentation code support running several times in parallel (as in, > > several processes with the instrumented code running concurrently)? > > gcc suppor

Re: Function Multiversioning Usability.

On Wed, Aug 17, 2011 at 8:12 AM, Richard Guenther wrote: > On Wed, Aug 17, 2011 at 4:52 PM, Xinliang David Li wrote: >> The gist of previous discussion is to use function overloading instead >> of exposing underlying implementation such as builtin_dispatch to the >> user. This new refined proposa

Re: FDO and LTO on ARM

On Wed, Aug 17, 2011 at 8:35 AM, Mike Hommey wrote: > On Thu, Aug 11, 2011 at 09:27:23AM -0700, Xinliang David Li wrote: >> > Maybe I have an idea as to why FDO doesn't work so well. Does the >> > instrumentation code support running several times in parallel (as in, >> > several processes with th

Re: Just what are rtx costs?

Richard Sandiford schrieb: I've been working on some patches to make insn_rtx_cost take account of the cost of SET_DESTs as well as SET_SRCs. But I'm slowly beginning to realise that I don't understand what rtx costs are supposed to represent. AIUI the rules have historically been: 1) Regist

Re: FDO and LTO on ARM

On Wed, Aug 17, 2011 at 10:22:16AM -0700, Xinliang David Li wrote: > On Wed, Aug 17, 2011 at 8:35 AM, Mike Hommey wrote: > > On Thu, Aug 11, 2011 at 09:27:23AM -0700, Xinliang David Li wrote: > >> > Maybe I have an idea as to why FDO doesn't work so well. Does the > >> > instrumentation code suppo

Re: [named address] ice-on-valid: in postreload.c:reload_cse_simplify_operands

http://gcc.gnu.org/ml/gcc/2011-08/msg00131.html Georg-Johann Lay a écrit: Ulrich Weigand wrote: Georg-Johann Lay wrote: Thanks, it works. OK, thanks for testing! [...] Bye, Ulrich Are you going to install that patch? Or maybe you already installed it? Then, I wonder how the following

Re: Just what are rtx costs?

On 08/17/2011 07:52 AM, Richard Sandiford wrote: cost = rtx_cost (SET_SRC (set), SET, speed); return cost> 0 ? cost : COSTS_N_INSNS (1); This ignores SET_DEST (the problem I'm trying to fix). It also means that constants that are slightly more expensive than a register -- somewhere in th

Re: PING: PATCH: Use int64 for x86 options

On Sun, 7 Aug 2011, H.J. Lu wrote: > HOST_BITS_PER_WIDE_INT isn't defined in target library. > I need to check if HOST_BITS_PER_WIDE_INT is defined > first. Here is the updated patch. As I said in , you need to check all CLVC_* uses for cases tha

Re: PING: PATCH: Use int64 for x86 options

On Wed, Aug 17, 2011 at 12:28 PM, Joseph S. Myers wrote: > On Sun, 7 Aug 2011, H.J. Lu wrote: > >> HOST_BITS_PER_WIDE_INT isn't defined in target library. >> I need to check if HOST_BITS_PER_WIDE_INT is defined >> first.  Here is the updated patch. > > As I said in

Re: PING: PATCH: Use int64 for x86 options

On Wed, 17 Aug 2011, H.J. Lu wrote: > On Wed, Aug 17, 2011 at 12:28 PM, Joseph S. Myers > wrote: > > On Sun, 7 Aug 2011, H.J. Lu wrote: > > > >> HOST_BITS_PER_WIDE_INT isn't defined in target library. > >> I need to check if HOST_BITS_PER_WIDE_INT is defined > >> first.  Here is the updated patch

Re: PING: PATCH: Use int64 for x86 options

On Wed, Aug 17, 2011 at 1:35 PM, Joseph S. Myers wrote: > On Wed, 17 Aug 2011, H.J. Lu wrote: > >> On Wed, Aug 17, 2011 at 12:28 PM, Joseph S. Myers >> wrote: >> > On Sun, 7 Aug 2011, H.J. Lu wrote: >> > >> >> HOST_BITS_PER_WIDE_INT isn't defined in target library. >> >> I need to check if HOST_B

GCC 4.6.2 Status Report (2011-08-17)

Status == GCC 4.6 branch remains open under normal release branch rules, accepting regression and documentation fixes. GCC 4.6.2 is tentatively planned for late September or early October. Quality Data Priority # Change from Last Report ---

Re: An unusual x86_64 code model

Second attempt: I now have a modified GCC 4.4.3 which recognizes -mcmodel=smallhigh; in CM_SMALLHIGH, pic_32bit_operand acts as it does for PIC (to get lea instead of movabs), and legitimate_address_p accepts SYMBOLIC_CONSTs with no indexing (for anything with a memory constraint). Beyond that, th

Re: Just what are rtx costs?

On Wed, 17 Aug 2011, Richard Sandiford wrote: > It also means > that constants that are slightly more expensive than a register -- > somewhere in the range [0, COSTS_N_INSNS (1)] -- end up seeming > cheaper than registers. Yes, perhaps some scale factor has to be applied to get reasonable cost gr

Fwd: C6X fails to build in FSF mainline

Forwarding this to the gcc list. Also Adding RTH to the CC since he helped Bernd to get the dwarf2 parts working correctly. -- Forwarded message -- From: Nick Clifton Date: Tue, Aug 16, 2011 at 5:14 AM Subject: C6X fails to build in FSF mainline To: ber...@codesourcery.com Cc: g