[LLVMdev] Vectors in structures

Renato Golin rengolin at systemcall.org
Tue Sep 28 15:14:20 PDT 2010


On 28 September 2010 22:08, Sandeep Patel <deeppatel1987 at gmail.com> wrote:
> Can we ask Lee or Richard or somebody for a ruling on why the spec is
> the way it is?

Hi Sandeep,

Al already explained what the requirements are (name mangling rules)
and that this is the only requirement.

As far as I understood (Al could correct me if I'm wrong), the
structures were used to hold the double values inside, since a double
aligns naturally at 64 bits, and you have to pack two doubles in a
structure for quad instructions (128 bits). Also, it's easy to name a
structure of two doubles, so the name mangling comes for free.

But this is as far as I go. I'd happily forward any further question
about the NEON (or any other ARM) ABI decisions.


> It would probably also help if armcc's arm_neon.h were
> available publicly for us to examine to further the discussion.

Indeed it would. I actually thought it was, TBH. It could be a
protection against patent trolling, I don't know, but will certainly
ask for a more definite answer.

As I said, I'm new at ARM and there's a lot I have to learn. Please be patient.


> What's being debated here seems like an optimization for compile time.
> I'm certainly in favor of that, but I can think of a ton of things I'd
> rather that we work on first that matter for correctness. For example,
> we're lacking proper EH, MCization of ARM attributes, accurate
> scheduling, etc.

Indeed! We're getting involved in such matters as well, as you may
have seen in other threads.

Unfortunately, we don't have spare resources to work full time on it
at the moment. We're doing our best with the time we have, to at least
share the knowledge and at most help implementing the core missing
features. I truly hope you don't take it as lack of interest (from me
or ARM).


-- 
cheers,
--renato

http://systemcall.org/

Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm



More information about the llvm-dev mailing list