This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
In message <3662B680.B6E559C5@americasm01.nt.com>you write: > Yeah. I got no improvement at all. I was more doing it to provide a > hook for those with more knowledge to work on it. What I typically find > is that double performance is acceptable but single float is > significantly worse. That's interesting. Certainly worth looking at if you can identify the hot loops for the poorly performing single precision code. > How do you go about making gcc avoid the fmpyadd and fmpysub > instructions for just the 8000? Well, we're going to need a couple switches. One which says to tune code for the PA8000, the other which says to generate PA8000 instructions. We've been using -msched=<blah> to control tuning of code for a particular processor variant in the PA port. So you'd need to have the compiler grok -msched=8000. -mpa-risc-2-0 would be used to enable PA2.0 ISA instructions like the fused multiply/add family of instructions. Then you can test pa_cpu to see if you're supposed to be tuning code for the PA8000. Then you make the call to the function which generates those insns conditional on not tuning code for the PA8000. See pa_reorg. > If we wanted to include the fused > multiply-add instructions, it appears that all the output would have to > be converted to pa2.0 opcodes, which includes revising gas. Does this > sound about right? Yes. Some of the BFD infrastructure is already in place. You'd need to add new entries to the opcode table and tweak the assembler & disassembler appropriately. jeff
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |