Maciej W. Rozycki wrote: > On Wed, 1 Dec 2004, Thiemo Seufer wrote: > > > The compiler was improved with PIC code in mind. The kernel is > > non-PIC, and can't allow explicit relocs by the compiler because > > of the weird code model used for 64bit kernels. This led to some > > degradation and even subtle failures for inline assembly code which > > relies on assumptions about earlier compiler's behaviour. > > What do you mean by "the weird code model" and what failures have you > observed? I think the bits are worth being done correctly, so I'd like > to know what problems to address. I had guessed you already know what i mean. :-) Current 64bit MIPS kernels run in (C)KSEG0, and exploit sign-extension to optimize symbol loads (2 instead of 6/7 instructions, the same as in 32bit kernels). This optimization relies on an assembler macro expansion mode which was hacked in gas for exactly this purpose. Gcc currently doesn't have something similiar, and would try to do a regular 64bit load with explicit relocs. I discussed this with Richard Sandiford a while ago, and the conclusion was to implement an explicit --msym32 option for both gcc and gas to improve register scheduling and get rid of the gas hack. So far, nobody came around to actually do the work for it. For the "subtle failures" part, we had some gas failures to handle dla because of the changed arguments. For userland (PIC) code, I've also seen additional load/store insn creeping in ll/sc loops. I believe there's a large amount of inline assembly code (not necessarily in the kernel) which relies on similiar assumptions. Thiemo