Hi,
I continued to work on vect_interleave and vect_extract implementation on NEON:
* debugged the compiler to find out what's the problem with
neon_vzip/vuzp<mode>_internal
* fixed it following Uli's advice
* checked how neon_vzip/vuzp<mode>_internal work for intrinsics by
writing tests
* fixed the patch according to Uli's comments
* now fully testing the patch
Thanks,
Ira
Hi,
I am trying to implement interleave_high/low and extract_even/odd
using vzip and vuzp instructions. I am attaching a patch that attempts
to do that. It uses already existing neon_vzip<mode>_internal. The
problem with it is that it doesn't express the fact that the two
outputs of vzip depend on both inputs, which causes wrong code
generation in CSE:
for
(a,b)<- vzip (c,d)
and
(e,f) <- vzip (g,d)
CSE decides that b==f, since on RTL level b and f depend only on d.
Here is neon_vzip<mode>_internal:
(define_insn "neon_vzip<mode>_internal"
[(set (match_operand:VDQW 0 "s_register_operand" "=w")
(unspec:VDQW [(match_operand:VDQW 1 "s_register_operand" "0")]
UNSPEC_VZIP1))
(set (match_operand:VDQW 2 "s_register_operand" "=w")
(unspec:VDQW [(match_operand:VDQW 3 "s_register_operand" "2")]
UNSPEC_VZIP2))]
"TARGET_NEON"
"vzip.<V_sz_elem>\t%<V_reg>0, %<V_reg>2"
[(set (attr "neon_type")
(if_then_else (ne (symbol_ref "<Is_d_reg>") (const_int 0))
(const_string "neon_bp_simple")
(const_string "neon_bp_3cycle")))]
)
Is there a way to properly mark the dependence?
Thanks,
Ira
Hi; this is a note to say that we have now produced a prerelease
tarball of qemu-linaro. (The first formal qemu-linaro release will
happen in sync with other toolchain group releases on 8th Feb.)
This prerelease is primarily to pipeclean the release process and
to allow work to start on producing Ubuntu and Linaro packages;
however it does include a number of useful bugfixes which are
required if you want to be able to boot a recent Linaro snapshot
on the beagle model. So the enthusiastic might like to build it
from source and give it a spin.
Like the Linaro kernel trees, the qemu-linaro tree aims to only
include patches we are confident will go upstream; at the moment
this means the OMAP3 support and ARM correctness fixes from
the qemu-meego tree, based on the qemu upstream trunk.
You can download the source tarball from:
https://launchpad.net/qemu-linaro/+milestone/2011.02
-- Peter Maydell
Hi,
What do people understand to be the expected semantics of IT blocks
in the cases below, of which there has been some confusion
in relation to a recent Qt issue.
The code in question had a sequence something like:
comparison
IT... EQ
blahEQ
TEQ
BEQ
The important bits here are that we have an IT EQ block and two special cases:
1) There is a TEQ in the IT block - are all comparisons in the block
allowed and do their effects immediately take
effect? As far as I can tell this is allowed and any flag changes are
used straight away;
2) There is a BEQ at the end of the IT block, as far as I can tell,
as long as the destination of the BEQ is close it shouldn't
make any difference if the BEQ is included in the IT block or not.
Does that match everyone elses understanding?
Dave
Hi all,
With gas, does anyone know of a way to create a section whose name is
based on that of the current section?
The specific requirement is to be able to define a generic macro like
the example "fixup" below, whose purpose is to record ancilliary data
related to some other section. To illustrate:
.macro fixup
100\@ :
.pushsection fixup<current section name>, "a"
.long 100\@b
.popsection
.endm
.text
...
fixup
.long sym1
...
.section .other, "ax"
...
fixup
.long sym2
The linux kernel uses a technique just like this for patching SMP
kernels at bootup to work on uniprocessor platforms (when
CONFIG_SMP_ON_UP is enabled), resulting in code looking something like
this:
void exit __attribute__ (( __section__ (".text.exit") ))
{
...
asm(
...
FIXUP("something")
...
);
}
Note that the inline asm may actually come out of a generic header
file rather than being explitly written for this invocation. So it
may have to be truly generic.
Is far as I have been able to determine, it's not possible to generate
sections named based on the current section. In practice, the kernel
puts all the fixups into a single section.
The downside of this is that when sections are selectively discarded
at link time (which in general may happen -- for example, Linux
discards the "module exit" code for drivers which are built into the
kernel and therefore never exit) there is no way to selectively
discard the related fixup entries. Currently the only solution is to
include all the module exit code in the image and discard it at
run-time when the kernel boots. This is obviously wasteful.
Attempting to discard that code at like time results in a link error,
since fixups refer to the removed sections.
Of course, the "fixup" macro could be given an extra parameter to name
the containing section, but the macro can then no longer be called in
a generic way: all the calls to that macro must be manually (and
buggily) maintained to ensure that the referenced section name is
correct, some object post-processing must be done before linking,
and/or a tool must be created to implement the missing assembler
functionality. Unfortunately, such solutions are likely to be too
fragile or complex to make it upstream.
It's interesting to note that the same problem will apply for any
section containing ancilliary data for another section. In
particular, it looks like either the ABI or the assembler has had to
grow a special-case workaround for this in order to support exception
unwind information sections generated by .fnstart ... .fnend in a sane
way: the unwind information sections get called .ARM.ex{idx,tab} for
.text, and .ARM.ex{idx,tab}<section> for any other section. As a
consequence, link-time discarding can handle this information
properly, but IMHO this is a bit of a cheat and admits the general
need to create sections with names based transparently on those of
other sections, without satisfying that need. .popsection is also an
example of such a cheat: most other aspects of assmbler state still
cannot be saved and restored.
In general, it would be useful if gas supported some general
reflective abilities: i.e., the ability to query the current assembler
state (section, subsection, active instruction set, active macro mode,
etc.) and/or the ability to wrap or hook existing pseudo-ops. For
example, the above problem would almost certainly solvable using
assembler macros (albeit painfully) if wrapper macros could be defined
for the section manipulation directives (section, .text, .data, .bss,
.pushsection, .popsection, .previous). However, supporting some magic
macro parameters reflecting the assembler state would be a lot
simpler.
As an example of the kind of behaviour I think would be useful, the
macro argument qualifier could be extended to allow macros to query
the assembler state in a backwards-compatible way; something like:
.macro fixup base_section:gas_current_section_name,
old_altmacro:gas_macro_mode
.altmacro
LOCAL fixup_location
fixup_location:
.pushsection \base_section\().fixup
.long 100\@b
.popsection
\old_altmacro
.endm
Existing assembler code will continue to work just fine with this approach.
Note how this also enables a local label to be generated hygenically,
by making it possible to save and restore the macro mode. Otherwise,
.altmacro (and hence LOCAL) is hard to use safely, since the initial
macro mode is unknown and can't be restored.
Any thoughts / comments?
Cheers.
---Dave
