While investigating some problems related to code generation I realized that OP_SYMADDR are systematically eliminated, the target address are simply replaced by the symbol itself. While it's not wrong per se as it all depends to the semantic we want to give to pseudos and the instructions and how high- or low-level we want to IR, I don't think it was the intention to remove them and more importantly I don't think it's desirable. Those OP_SYMADDR allowed to make a clear separation between a symbol (a name with a type and info for storage & linkage) and its address (which can be stored in memory or in a register and on which arithmetic operations can then be done on it). Once these addresses are replaced by the symbol itself, those symbols can appears almost everywhere in the linearized code: - in calls' arguments, - in adds and subs (while doing pointer arithmetic), - in casts, - in load & stores, - ... and they complicate things considerably once you begin to be interested concretly in things after linearization & simplification since soon or later you will need the address anyway. So my question is: "is there a good reason to eliminate those instructions?", and ultimately: "is there any objections to the following patch?". -- Luc Van Oostenryck --- diff --git a/simplify.c b/simplify.c index 5d00937f1..a84e4787f 100644 --- a/simplify.c +++ b/simplify.c @@ -1159,7 +1159,7 @@ int simplify_instruction(struct instruction *insn) case OP_SYMADDR: if (dead_insn(insn, NULL, NULL, NULL)) return REPEAT_CSE | REPEAT_SYMBOL_CLEANUP; - return replace_with_pseudo(insn, insn->symbol); + return 0; case OP_CAST: case OP_SCAST: case OP_FPCAST: -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
