On Mon, Jun 14, 2010 at 03:14:37PM +0200, Michael Matz wrote:
> Doing the change in GNU as has the advantage that all insn lengths are
> available without any work, i.e. it will handle e.g. inline asm; and that
> relaxation also is implemented just fine (it exists already in order to
> decide wh
Hi,
On Sun, 13 Jun 2010, H.J. Lu wrote:
> > We shouldn't turn GNU x86 assembler into an optimizing assembler. Next
> > people may ask assembler to remove redundant instructions, ...
Well, but currently nobody is asking for such thing, right?
> > Right now, when something goes wrong, people don
On Sat, Jun 12, 2010 at 8:15 AM, H.J. Lu wrote:
> On Fri, Jun 11, 2010 at 3:42 PM, Quentin Neill
> wrote:
>> On Thu, Jun 10, 2010 at 5:23 PM, H.J. Lu wrote:
>>> [snip]
>>> x86 assembler isn't an optimizing assembler. -mtune only does
>>> instruction selection. What you are proposing sounds like
On Jun 13, 2010, at 7:35 AM, Joern Rennecke wrote:
> An even if you have a suitable text for the assembler, to link the compiler
> with the assembler requires to merge to two complex build systems, and
> resolve symbol name clash issues.
Not trying to be inflammatory, but if you guys are really se
Andi Kleen writes:
> [...]
> Yes but you can't easily pass data back, like accurate instruction lengths.
Wouldn't it be too late by then? Or are you imagining having the
compiler pass trial data to the assembler to create a feedback loop?
- FChE
Quoting Andi Kleen :
On Sun, Jun 13, 2010 at 07:14:03AM -0400, Joern Rennecke wrote:
Quoting Andi Kleen :
I admit I haven't looked into gas code, but naively it can't
be all that difficult to e.g. run gas as a thread and
pass the text input through some shared memory buffer?
If you are gener
On Sun, Jun 13, 2010 at 07:14:03AM -0400, Joern Rennecke wrote:
> Quoting Andi Kleen :
>> I admit I haven't looked into gas code, but naively it can't
>> be all that difficult to e.g. run gas as a thread and
>> pass the text input through some shared memory buffer?
>
> If you are generating text an
Quoting Andi Kleen :
I admit I haven't looked into gas code, but naively it can't
be all that difficult to e.g. run gas as a thread and
pass the text input through some shared memory buffer?
If you are generating text anyway, there should be little difference to
the existing -pipe option - at l
> It would help compilation time a little bit, but generating the
> assembly code and running the entire assembler is a fairly small
> percentage of the overall compilation time--e.g., 3%. It's worth
> doing a fair amount of work to speed up compilation by 3%, but linking
> the assembler into gcc
Andi Kleen writes:
> But if you need more why can't you just link the whole assembler
> into gcc? That would hopefully speed up compilation too
> (e.g. over time the text generation of instructions could
> be bypassed)
It would help compilation time a little bit, but generating the
assembly code
On Fri, Jun 11, 2010 at 3:42 PM, Quentin Neill
wrote:
> On Thu, Jun 10, 2010 at 5:23 PM, H.J. Lu wrote:
>> [snip]
>> x86 assembler isn't an optimizing assembler. -mtune only does
>> instruction selection. What you are proposing sounds like an optimizing
>> assembler to me. Are we going to suppor
Quentin Neill writes:
>
> Another option would be to expose some subset of the assembler
> functionality as a plugin to GCC (similar to how gold is used) to
> extract the instruction sizes. Any comments on that approach?
AFAIK gcc already does keep track of instruction lengths
(e.g. for LOOP),
On Thu, Jun 10, 2010 at 5:23 PM, H.J. Lu wrote:
> [snip]
> x86 assembler isn't an optimizing assembler. -mtune only does
> instruction selection. What you are proposing sounds like an optimizing
> assembler to me. Are we going to support scheduling, macro, ...?
> --
> H.J.
Just to clarify, we ar
On Fri, Jun 11, 2010 at 02:09:33PM -0500, Quentin Neill wrote:
> Currently GCC doesn't compute the current encoding offset (doesn't
> know mnemonic/opcode lengths),
That's not true, gcc for i?86/x86_64 actually calculates the length and for
most of the commonly used insns correctly, I've spent so
On Fri, Jun 11, 2010 at 12:09 PM, Quentin Neill
wrote:
> On Fri, Jun 11, 2010 at 10:58 AM, Daniel Jacobowitz
> wrote:
>> On Thu, Jun 10, 2010 at 09:48:24PM -0500, Quentin Neill wrote:
> [snip]
>>> Does this qualify as a form of what you are suggesting? Because this
>>> is exactly what is being p
On Fri, Jun 11, 2010 at 10:58 AM, Daniel Jacobowitz
wrote:
> On Thu, Jun 10, 2010 at 09:48:24PM -0500, Quentin Neill wrote:
[snip]
>> Does this qualify as a form of what you are suggesting? Because this
>> is exactly what is being proposed:
>>
>> .balign 8 # start window
>> i
On Thu, Jun 10, 2010 at 09:48:24PM -0500, Quentin Neill wrote:
> > On the other hand, I'm not going to argue that it's a lot of work.
Missing "not" !
> When you say "put assertions in the assembler output" I understood it
> to mean "in the assembly source code output by the compiler", not "the
>
On Thu, Jun 10, 2010 at 5:40 PM, Daniel Jacobowitz
wrote:
> On Thu, Jun 10, 2010 at 02:03:03PM -0600, Jeff Law wrote:
>> That adds quite a bit of complication to the compiler though --
>> getting the instruction lengths right (and thus proper packing &
>> alignment) can be extremely difficult. I
On Thu, Jun 10, 2010 at 02:03:03PM -0600, Jeff Law wrote:
> That adds quite a bit of complication to the compiler though --
> getting the instruction lengths right (and thus proper packing &
> alignment) can be extremely difficult. I did some experiments with
> this on a target with *fixed* instru
On Thu, Jun 10, 2010 at 3:03 PM, Jeff Law wrote:
> On 06/10/10 13:52, H.J. Lu wrote:
>> On Thu, Jun 10, 2010 at 11:05 AM, Quentin Neill
>> wrote:
>>> Cross-posting Reza's call for feedback to the binutils list since it
>>> is relevant - s ee the last few paragraphs regarding how to
>>> "solve th
On Thu, Jun 10, 2010 at 3:09 PM, Quentin Neill
wrote:
> On Thu, Jun 10, 2010 at 4:08 PM, H.J. Lu wrote:
>> On Thu, Jun 10, 2010 at 1:59 PM, Quentin Neill
>> wrote:
>>> On Thu, Jun 10, 2010 at 3:03 PM, Jeff Law wrote:
On 06/10/10 13:52, H.J. Lu wrote:
> On Thu, Jun 10, 2010 at 11:05 AM,
On 06/10/10 13:52, H.J. Lu wrote:
On Thu, Jun 10, 2010 at 11:05 AM, Quentin Neill
wrote:
Cross-posting Reza's call for feedback to the binutils list since it
is relevant -
see the last few paragraphs regarding how to "solve the alignment problem".
Original thread: http://gcc.gnu.org/ml/gc
On Thu, Jun 10, 2010 at 4:08 PM, H.J. Lu wrote:
> On Thu, Jun 10, 2010 at 1:59 PM, Quentin Neill
> wrote:
>> On Thu, Jun 10, 2010 at 3:03 PM, Jeff Law wrote:
>>> On 06/10/10 13:52, H.J. Lu wrote:
On Thu, Jun 10, 2010 at 11:05 AM, Quentin Neill
wrote:
> Cross-posting Reza's call f
Quoting Jeff Law :
That adds quite a bit of complication to the compiler though -- getting
the instruction lengths right (and thus proper packing & alignment) can
be extremely difficult. I did some experiments with this on a target
with *fixed* instruction lengths a while back and even though t
On Thu, Jun 10, 2010 at 11:05 AM, Quentin Neill
wrote:
> Cross-posting Reza's call for feedback to the binutils list since it
> is relevant -
> see the last few paragraphs regarding how to "solve the alignment problem".
>
> Original thread: http://gcc.gnu.org/ml/gcc/2010-06/threads.html#00402
>
>
On Thu, Jun 10, 2010 at 1:59 PM, Quentin Neill
wrote:
> On Thu, Jun 10, 2010 at 3:03 PM, Jeff Law wrote:
>> On 06/10/10 13:52, H.J. Lu wrote:
>>> On Thu, Jun 10, 2010 at 11:05 AM, Quentin Neill
>>> wrote:
Cross-posting Reza's call for feedback to the binutils list since it
is relevant
Cross-posting Reza's call for feedback to the binutils list since it
is relevant -
see the last few paragraphs regarding how to "solve the alignment problem".
Original thread: http://gcc.gnu.org/ml/gcc/2010-06/threads.html#00402
Not sure if followups should occur on one list or both.
--
Quentin N
Hi,
We are in the process of adding a feature to GCC to take advantage of a new
hardware feature in the latest AMD micro processor. This feature requires a
certain mix, ordering and alignments in instruction sequences to obtain the
expected hardware performance.
I am asking the community t
28 matches
Mail list logo
