https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118012
--- Comment #10 from Georg-Johann Lay <gjl at gcc dot gnu.org> --- (In reply to Andrew Pinski from comment #9) > Basically gimple should be almost all target indepdendent except in the late > stages. The problem is that some canonicalizations are very expensive on some targets, and in some cases there is no way to roll back or work around, like for branching / non-branching code, or when the middle-end introduces libcalls. > One big idea is to change expand to expand things from gimple to rtl better. > One way of doing this is add more optabs (and direct internal functions) and > have isel pattern match into these optabs. Sould like quite some project... > Expanding it for scalar modes and using it for isel can happen. How would the backend chime in? Only per costs, or is there more control qua new standard insns?