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't
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 which
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
Quoting Andi Kleen a...@firstfloor.org:
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
On Sun, Jun 13, 2010 at 07:14:03AM -0400, Joern Rennecke wrote:
Quoting Andi Kleen a...@firstfloor.org:
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
Quoting Andi Kleen a...@firstfloor.org:
On Sun, Jun 13, 2010 at 07:14:03AM -0400, Joern Rennecke wrote:
Quoting Andi Kleen a...@firstfloor.org:
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
Andi Kleen a...@firstfloor.org 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
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
On Sat, Jun 12, 2010 at 8:15 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Fri, Jun 11, 2010 at 3:42 PM, Quentin Neill
quentin.neill@gmail.com wrote:
On Thu, Jun 10, 2010 at 5:23 PM, H.J. Lu hjl.to...@gmail.com wrote:
[snip]
x86 assembler isn't an optimizing assembler. -mtune only does
Quentin Neill quentin.neill@gmail.com 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
On Fri, Jun 11, 2010 at 3:42 PM, Quentin Neill
quentin.neill@gmail.com wrote:
On Thu, Jun 10, 2010 at 5:23 PM, H.J. Lu hjl.to...@gmail.com wrote:
[snip]
x86 assembler isn't an optimizing assembler. -mtune only does
instruction selection. What you are proposing sounds like an optimizing
Andi Kleen a...@firstfloor.org 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
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
output
On Fri, Jun 11, 2010 at 10:58 AM, Daniel Jacobowitz
d...@codesourcery.com 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
On Fri, Jun 11, 2010 at 12:09 PM, Quentin Neill
quentin.neill@gmail.com wrote:
On Fri, Jun 11, 2010 at 10:58 AM, Daniel Jacobowitz
d...@codesourcery.com 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?
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
On Thu, Jun 10, 2010 at 5:23 PM, H.J. Lu hjl.to...@gmail.com 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
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
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
On Thu, Jun 10, 2010 at 1:59 PM, Quentin Neill
quentin.neill@gmail.com wrote:
On Thu, Jun 10, 2010 at 3:03 PM, Jeff Law l...@redhat.com wrote:
On 06/10/10 13:52, H.J. Lu wrote:
On Thu, Jun 10, 2010 at 11:05 AM, Quentin Neill
quentin.neill@gmail.com wrote:
Cross-posting Reza's call
On Thu, Jun 10, 2010 at 11:05 AM, Quentin Neill
quentin.neill@gmail.com 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:
Quoting Jeff Law l...@redhat.com:
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
On Thu, Jun 10, 2010 at 4:08 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Thu, Jun 10, 2010 at 1:59 PM, Quentin Neill
quentin.neill@gmail.com wrote:
On Thu, Jun 10, 2010 at 3:03 PM, Jeff Law l...@redhat.com wrote:
On 06/10/10 13:52, H.J. Lu wrote:
On Thu, Jun 10, 2010 at 11:05 AM, Quentin
On 06/10/10 13:52, H.J. Lu wrote:
On Thu, Jun 10, 2010 at 11:05 AM, Quentin Neill
quentin.neill@gmail.com 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
On Thu, Jun 10, 2010 at 3:09 PM, Quentin Neill
quentin.neill@gmail.com wrote:
On Thu, Jun 10, 2010 at 4:08 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Thu, Jun 10, 2010 at 1:59 PM, Quentin Neill
quentin.neill@gmail.com wrote:
On Thu, Jun 10, 2010 at 3:03 PM, Jeff Law l...@redhat.com
On Thu, Jun 10, 2010 at 3:03 PM, Jeff Law l...@redhat.com wrote:
On 06/10/10 13:52, H.J. Lu wrote:
On Thu, Jun 10, 2010 at 11:05 AM, Quentin Neill
quentin.neill@gmail.com wrote:
Cross-posting Reza's call for feedback to the binutils list since it
is relevant - s ee the last few
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*
On Thu, Jun 10, 2010 at 5:40 PM, Daniel Jacobowitz d...@codesourcery.com
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
28 matches
Mail list logo
