Michael Cree wrote:

> On 15/07/2012, at 8:50 AM, Jonathan Nieder wrote:

>>                   gcc takes full advantage by converting the get_be32
>> calls back to a load and bswap and producing a whole bunch of
>> unaligned access traps.
> Alpha does not have a bswap (or similar) instruction.
>                                    .  If the pointer is unaligned
> then two neighbouring aligned 32bit loads are required to ensure
> that all four bytes are loaded.  If the pointer is aligned then a
> single 32bit load gets all the four bytes.  Having never looked at
> the generated assembler code, I nevertheless suspect that is the
> guts of the optimisation --- the compiler can eliminate an access to
> memory if it knows the pointer is aligned.

How about:

        gcc takes full advantage by using a single 32-bit load,
        resulting in a whole bunch of unaligned access traps.

You can see the generated assembler with "make block-sha1/sha1.s" and
reading the resulting sha1.s file in the current working directory
(oops).  I don't have an alpha cross-compiler installed or access to
an alpha to check for myself.

-- >8 --
Subject: Makefile: fix location of listing produced by "make subdir/foo.s"

When I invoke "make block-sha1/sha1.s", 'make' runs $(CC) -S without
specifying where it should put its output and the output ends up in
./sha1.s.  Confusing.

Add an -o option to the .s rule to fix this.  We were already doing
that for most compiler invocations but had forgotten it for the
assembler listings.

Signed-off-by: Jonathan Nieder <jrnie...@gmail.com>

 Makefile |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index dc709029..e8d2798f 100644
--- a/Makefile
+++ b/Makefile
@@ -2230,7 +2230,7 @@ $(ASM_OBJ): %.o: %.S GIT-CFLAGS $(missing_dep_dirs)
+       $(QUIET_CC)$(CC) -o $@ -S $(ALL_CFLAGS) $(EXTRA_CPPFLAGS) $<
 # Take advantage of gcc's on-the-fly dependency generation

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to