On Fri, Jun 25, 2010 at 8:34 AM, Eric Botcazou wrote:
>> Minus whitespace changes it seems to be
>>
>> ! if (lhs_free && (is_gimple_reg (rhs) ||
>> is_gimple_min_invariant (rhs)))
>> rhs_free = true;
>>
>> vs.
>>
>> ! if (lhs_free
>> ! && (is_gimple_
On Fri, Jun 25, 2010 at 8:15 AM, Jonathan Adamczewski
wrote:
> On 25/06/10 06:39, Richard Guenther wrote:
>> There are btw. some bugs wrt accounting of functions called once
>> being inlined in 4.5 which were fixed on trunk which allow extra
>> inlining.
>>
>
> Are these changes likely to make it
> I do think so.
Huh? What do your version and mine return for the following assignment?
void foo (int i)
{
struct S s;
s.a = i;
}
> Which in the following example makes i = *p not likely eliminated
> but makes j = *q likely eliminated.
>
> void foo (int *p, struct X *q)
> {
> int i;
>
On Fri, Jun 25, 2010 at 12:45 PM, Eric Botcazou wrote:
>> I do think so.
>
> Huh? What do your version and mine return for the following assignment?
>
> void foo (int i)
> {
> struct S s;
> s.a = i;
> }
>
>> Which in the following example makes i = *p not likely eliminated
>> but makes j = *q l
> On Fri, Jun 25, 2010 at 8:15 AM, Jonathan Adamczewski
> wrote:
> > On 25/06/10 06:39, Richard Guenther wrote:
> >> There are btw. some bugs wrt accounting of functions called once
> >> being inlined in 4.5 which were fixed on trunk which allow extra
> >> inlining.
> >>
> >
> > Are these changes
On Thu, Jun 24, 2010 at 11:50:52AM -0700, Taras Glek wrote:
> Just wanted to give a heads up on what might be the biggest
> compiler-upgrade-related performance difference we've seen at Mozilla.
>
> We switched gcc4.3 for gcc4.5 and our automated benchmarking
> infrastructure reported 4-19% sl
On Fri, Jun 25, 2010 at 1:02 PM, Richard Guenther
wrote:
> On Fri, Jun 25, 2010 at 12:45 PM, Eric Botcazou wrote:
>>> I do think so.
>>
>> Huh? What do your version and mine return for the following assignment?
>>
>> void foo (int i)
>> {
>> struct S s;
>> s.a = i;
>> }
>>
>>> Which in the fol
Hi,
On Fri, 25 Jun 2010, Jan Hubicka wrote:
> I would be also very interested to know how profile feedback works in this
> case
> (and why it does not work in previous releases).
Profiling multi-threading programs needs -fprofile-correction that appeared
only in 4.4 (but I have no idea whether
Hi,
everything was fine until this morning, now upon make-check in the v3
dir, during the final link for testsuite_shared.so, ld spills:
relocation R_X86_64_PC32 against symbol
`__gnu_cxx::__common_pool<__gnu_cxx::__pool, true>::_S_get_pool()' can
not be used when making a shared object; recompil
On Fri, Jun 25, 2010 at 06:10:56AM -0700, Jan Hubicka wrote:
> When you compile with -Os, the inlining happens only when code size reduces.
> Thus we pretty much care about the code size metrics only. I suspect the
> problem here might be that normal C++ code needs some inlining to make
> abstract
> Hi,
>
> On Fri, 25 Jun 2010, Jan Hubicka wrote:
>
> > I would be also very interested to know how profile feedback works in this
> > case
> > (and why it does not work in previous releases).
>
> Profiling multi-threading programs needs -fprofile-correction that appeared
> only in 4.4 (but I h
On 06/03/2010 05:24 AM, Uros Bizjak wrote:
> ; Current assemblers are broken and do not allow @GOTOFF in
> ; ought but a memory context.
>
> Code, following this comment disables or special-cases
> "pic_symbolic_operands".
>
> I'm investigating, which "current assemblers"
Richard Henderson writes:
> Note that this *is* a memory context. The problematic cases were
>
> addl $...@gotoff, %eax
>
> which needed to be written as
>
> lea x...@gotoff(%eax), %eax
>
> to satisfy the memory context requirement of the broken assemblers.
The Solaris 8/x86 assembler handl
On Fri, Jun 25, 2010 at 7:50 AM, Paolo Carlini wrote:
> Hi,
>
> everything was fine until this morning, now upon make-check in the v3
> dir, during the final link for testsuite_shared.so, ld spills:
>
> relocation R_X86_64_PC32 against symbol
> `__gnu_cxx::__common_pool<__gnu_cxx::__pool, true>::_
On 06/25/2010 11:09 AM, Rainer Orth wrote:
> The Solaris 8/x86 assembler handles the first form just fine, with
> output identical to gas 2.20.1.
Excellent.
r~
On Fri, Jun 25, 2010 at 11:38 AM, H.J. Lu wrote:
> On Fri, Jun 25, 2010 at 7:50 AM, Paolo Carlini
> wrote:
>> Hi,
>>
>> everything was fine until this morning, now upon make-check in the v3
>> dir, during the final link for testsuite_shared.so, ld spills:
>>
>> relocation R_X86_64_PC32 against s
On 06/25/2010 08:48 PM, H.J. Lu wrote:
> I opened a bug:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44671
>
Thanks HJ. Luckily it's friday, but we have quite a bit of ongoing
activity in the library, I really hope that over the weekend the
offending commit is properly tweaked or otherwise r
Hello,
Can anybody explain how the register allocation is handled in GCC? Is it
done together with the general register allocation? or GCC has a separate phase
to handle them separately?
Any pointer to the source code that I can take a look? Thanks
Peng
BLUE 3TOO writes:
> Can anybody explain how the register allocation is handled in GCC?
> Is it done together with the general register allocation? or GCC
> has a separate phase to handle them separately?
There is no separate vector register allocator. All classes of
registers are al
Ian, thanks a lot for the help. Is there any document
about IRA (e.g. how the SIMD registers of a
specific architecture is exposed to the allocation
process)? or the only option is the read the code?
what is the best information source for a beginner on gcc?
Thanks again.
-
BLUE 3TOO writes:
> Ian, thanks a lot for the help. Is there any document
> about IRA (e.g. how the SIMD registers of a
> specific architecture is exposed to the allocation
> process)? or the only option is the read the code?
Vlad described IRA in a paper published in the 2007 GCC Summit
proc
Hi,
On Fri, Jun 25, 2010 at 11:38:39AM -0700, H.J. Lu wrote:
> On Fri, Jun 25, 2010 at 7:50 AM, Paolo Carlini
> wrote:
> > Hi,
> >
> > everything was fine until this morning, now upon make-check in the v3
> > dir, during the final link for testsuite_shared.so, ld spills:
> >
> > relocation R_X86
22 matches
Mail list logo
