On Sun, Feb 3, 2013 at 12:09 PM, Jan Hubicka wrote:
>> On 02/01/2013 12:38 AM, Jan Hubicka wrote:
>> > Doing the extensions at caller side always is however IMO a preformance
>> > bug in
>> > GCC. We can definitly drop them at -Os, for non-PRS targets and for calls
>> > within compilation unit w
> On 02/01/2013 12:38 AM, Jan Hubicka wrote:
> > Doing the extensions at caller side always is however IMO a preformance bug
> > in
> > GCC. We can definitly drop them at -Os, for non-PRS targets and for calls
> > within compilation unit where we know that GCC is not really producing
> > code lik
On 02/01/2013 12:38 AM, Jan Hubicka wrote:
> Doing the extensions at caller side always is however IMO a preformance bug in
> GCC. We can definitly drop them at -Os, for non-PRS targets and for calls
> within compilation unit where we know that GCC is not really producing
> code like in Michael's
> On 01/30/2013 04:49 PM, Michael Matz wrote:
> > Hmm? GCC generates code that doesn't rely on the extension taking place.
>
> Sure, I didn't mean to suggest it was: it's LLVM that's incorrect.
Yes, that is LLVM bug. I am surprised that it went unnoticed for so long,
but I guess it is difficult
> > Well, it's hardly an optimization if it's incorrect, and it seems to be
> > incorrect. As the old saying goes, I can make your code infinitely fast
> > if you don't care about the results.
>
> It's incorrect to rely on the extension taking place. It's not incorrect to
> do the extension.
Th
On 01/30/2013 04:49 PM, Michael Matz wrote:
> Hmm? GCC generates code that doesn't rely on the extension taking place.
Sure, I didn't mean to suggest it was: it's LLVM that's incorrect.
Thanks for the explanation.
Andrew.
Hi,
On Wed, 30 Jan 2013, Andrew Haley wrote:
> >>> It's an optimization to do so to avoid partial register stalls.
> >>
> >> Well, it's hardly an optimization if it's incorrect, and it seems to
> >> be incorrect.
Hmm? GCC generates code that doesn't rely on the extension taking place.
> >> As
On 01/30/2013 03:55 PM, Andrew Haley wrote:
>> >
>> > It's incorrect to rely on the extension taking place. It's not incorrect
>> > to
>> > do the extension.
> Sure, I understand that, but I am completely baffled as to how
> extending at a call site avoids partial register stalls if a callee
> c
On 01/30/2013 03:51 PM, Richard Biener wrote:
> On Wed, Jan 30, 2013 at 4:49 PM, Andrew Haley wrote:
>> On 01/30/2013 03:46 PM, Richard Biener wrote:
>>> On Wed, Jan 30, 2013 at 3:22 PM, Andrew Haley wrote:
The problem is that LLVM assumes that values are extended at a call. GCC
d
On Wed, Jan 30, 2013 at 4:49 PM, Andrew Haley wrote:
> On 01/30/2013 03:46 PM, Richard Biener wrote:
>> On Wed, Jan 30, 2013 at 3:22 PM, Andrew Haley wrote:
>>> Hi,
>>>
>>> On 01/30/2013 02:18 PM, Michael Matz wrote:
>>>
On Wed, 30 Jan 2013, Andrew Haley wrote:
> I'm looking at Sect
On 01/30/2013 03:46 PM, Richard Biener wrote:
> On Wed, Jan 30, 2013 at 3:22 PM, Andrew Haley wrote:
>> Hi,
>>
>> On 01/30/2013 02:18 PM, Michael Matz wrote:
>>
>>> On Wed, 30 Jan 2013, Andrew Haley wrote:
>>>
I'm looking at Section 3.2.3, Parameter Passing.
http://artfiles.org/kernel.or
On Wed, Jan 30, 2013 at 3:22 PM, Andrew Haley wrote:
> Hi,
>
> On 01/30/2013 02:18 PM, Michael Matz wrote:
>
>> On Wed, 30 Jan 2013, Andrew Haley wrote:
>>
>>> I'm looking at Section 3.2.3, Parameter Passing.
>>> http://artfiles.org/kernel.org/pub/scm/devel/binutils/hjl/x86-64-psabi.git/
>>>
>>> I
Hi,
On 01/30/2013 02:18 PM, Michael Matz wrote:
> On Wed, 30 Jan 2013, Andrew Haley wrote:
>
>> I'm looking at Section 3.2.3, Parameter Passing.
>> http://artfiles.org/kernel.org/pub/scm/devel/binutils/hjl/x86-64-psabi.git/
>>
>> I still cannot tell whether parameters should or should not be sig
Hi,
On Wed, 30 Jan 2013, Andrew Haley wrote:
> I'm looking at Section 3.2.3, Parameter Passing.
> http://artfiles.org/kernel.org/pub/scm/devel/binutils/hjl/x86-64-psabi.git/
>
> I still cannot tell whether parameters should or should not be sign- or
> zero-extended when they are moved into regis
[Resending, this time CC:'d to GCC list.]
I'm looking at Section 3.2.3, Parameter Passing.
http://artfiles.org/kernel.org/pub/scm/devel/binutils/hjl/x86-64-psabi.git/
I still cannot tell whether parameters should or should not be sign- or
zero-extended when they are moved into registers at a call
15 matches
Mail list logo
