On Thu, 6 Sep 2012, Iyer, Balaji V wrote: > >Concepts such as "pentium_4" are architecture-specific and have no place in > >front-end files. This whole mapping from one sort of string to another > >belongs > >within the back end. > > Please excuse me if I am "beating this horse to death." I am asking this > to make sure I am understanding this correctly before I start > re-implementing things. I am not very clear about whether the problem is > the function's location or the place where it is called? Can you please > clarify? Things like pentium_4 are part of the language (please see > processor clause in the pg 34 of the spec) and all I was doing was to > parse that and was doing a string matching and substituting one string > for the next. All the processing and picking of instructions are done by > the existing backend.
That indicates a significant deficiency in the structure of the specification. It would best be reworked to separate the architecture-independent specification from architecture-specific annexes. Every reference to something architecture-specific should instead say how things are defined by the architecture annex (for example, that the architecture annex specifies the tokens accepts for the processor clause and the default vector length). There should be a defined way for architecture annexes to be added or updated for new architectures. In addition, descriptions such as "Calls to functions other than other elemental functions and the intrinsic short vector math libraries provided with the Intel compilers" are clearly unsuitable for a specification of a language extension. Until the specification is cleaned up to follow normal good practice for such specifications, the documentation included with GCC will need, along with a pointer to the specification, detail how it is amended to be properly architecture-independent and what are considered to be the architecture annexes followed by GCC. And those parts of the specification that clearly would naturally vary from architecture to architecture will need to have the architecture-specific parts implemented through target hooks, not directly in the architecture-independent compiler. And make it as easy as possible for people to add test coverage for new architectures. Having looked at bits of the specification now, I may as well point out another, unrelated, issue that needs fixing in the specification: "Elemental functions cannot be virtual, and can only be called directly, not through a function pointer". As I noted on the WG14 reflector when a similar issue appeared in a draft of the IEEE 758-2008 bindings, all C function calls are through function pointers - that's how the C standard defines them - so you need to say (in the specification, not here) what's meant in actual C standard terms, and make sure the implementation follows that, and make sure there are testcases verifying that this constraint is diagnosed. -- Joseph S. Myers jos...@codesourcery.com
