I'm resubmitting the gcc ports to TILE-Gx and TILEPro as replies to this email. The resubmission addresses the feedback made by Richard Henderson in:
http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01232.html, and http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01247.html Feedback by Joseph Myers made in: http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01385.html http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01387.html was addressed in a previous submission. Here is a summary of the issues addressed: Changes made to both ports: - added vector patterns for suitable vector ops. - cleaned up various move pattens, deleting dead alternatives, deleting redundant immediate insn_and_split patterns, and delete unnecessary movdi multi-word move pattern (tilepro only). - added extra insv patterns. - combined all the conditional moves into one pattern. - combined "*lh" and "*extendhisi2" pattern, and "*lb" and "*extendqihi2". - partially remove the divsi stubs that were there to work around an old gcc bug that has been partially fixed. Previously gcc would not turn divide by constant into multiply by constant unless there is a pattern for the divide of the given mode. It now seems to do better, but we still need the stub on tilegx, else it turns 32-bit divide by constant into 64-bit multiply by constant. - wrap the GOT and TLS unspec addresses in const, and handle them with a single pattern. - add support for post_{inc,dec,modify} addressing modes. - fixed invalid rtl sharing in alloca handling routines. - use REG_CFA_* notes in prologue and epilogue. - Use post-inc load in TARGET_ASM_TRAMPOLINE_TEMPLATE. - converted the following to target hooks: LIBCALL_VALUE, FUNCTION_VALUE_REGNO_P, GO_IF_LEGITIMATE_ADDRESS. Delete GO_IF_MODE_DEPENDENT_ADDRESS and use the default. - use the new atomics_ names and patterns. Changes made to tilegx port: - merged the AND patterns. - add patterns that sign extends an SI result to DI for all the 32-bit insns. Here are replies to a few feedback items: > optabs.c will do exactly this if the pattern is not present. Similarly > for the DImode logicals (popcount, parity, etc). I tried taking out the patterns for ctzdi2, clzdi2, ffsdi2, paritydi2, and popcountdi2, and I found that the compiler generates libgcc function calls for all of them except clzdi2. For clzdi2 the tilepro pattern is better than the default because it uses mvnz to get rid of a branch. This is all true for gcc 4.4.6... gcc 4.7 does not use my patterns at all, which seems like a bug. I need the paritysi2 as well; without it the compiler does not generate code for paritydi2 properly. > Post merge, consider changing this to simple_return to enable shrink > wrapping. This may also involve epilogue unwind fixups though. I have not enabled the "simple_return" pattern. On the tile ports, the prologue defines a register not accounted for in the shrink wrapping code (the PIC_TEXT_LABEL_REGNUM register). Is there a plan to provide a target hook to support this? I did verify that shrink wrapping work properly when I account for this register. > I also don't see support for AND addresses, as for lw_na. And yet you > seem to be using those addressing modes in tilepro_expand_unaligned_load. > I can only assume these are failing validate_mem, and forcing the > address into a register first? Yeah there is no AND addressing mode; the addresses are being put into registers. > Why not use gp-relative references? A small matter of extending the > assembler with new relocations, perhaps. We don't have that support in the tool chain currently. I can look into it, but I haven't done it. > > /* We represent all SI values as sign-extended DI values in > > registers. */ > > #define TRULY_NOOP_TRUNCATION(OUTPREC, INPREC) \ > > ((INPREC) <= 32 || (OUTPREC) > 32) > > I think you should be *very* careful before you insist on this. Do > you not have a memory mode that ignores the high bits for 32-bit > pointers? From the description of "memoryReadWord", it does seem like > you've got modes that pre-process input addresses. Unfortunately all the address bits are read; we do not ignore the high bits of 32-bit pointers. > MIPS uses this because, technically, the 32-bit operation insns > produce undefined results when given inputs that are not > sign-extended. I see no such restriction in the TileGx manual. I think the issue is that we do not have 32-bit compares; we just reuse the 64-bit ones. This requires that the inputs be sign extended. > At least in 64-bit pointer mode, I think you should drop this and make > sure that you've got appropriate sign_extend patterns for all of the > "x" insns. Similar to how x86_64 does for the zero_extend patterns. I've added the sign_extend patterns for the 32-bit insns. Please let me know if there is anything I need to address. Thanks, Walter Lee
