> We could stop using $at but why is that beneficial? Why does universally
> reserving a register to support an (uncommon) construct make more sense to > you than having that construct properly indicate that it may clobber a > specific register? The former sounds like a sledgehammer to me. Totally is, but blindly adding clobbers is much the same, just a more focused hammer. I'm not against it, mostly that the original discussion didn't say any of these things. > The work pre-dates me but as far as I can tell the developers of the Mips > port deliberately decided not to reserve $at and emit code in '.set noat' > mode. Presumably this was to see how much of gcc's $at usage is essential > to the correct operation of the output code. It turns out that No, it's been known for a while that the use of macro instructions isn't a good idea in the compiler. It's why we switched the gcc port away from using them as well. > the answer is 'almost none'. In LLVM's CodeGen, $at isn't particularly > special. The few instructions/macros/relocations that need a temporary > register to be $at describe this with an implicit def of AT. Branches like > B are a good example of this (it's worth pointing out that most of the time > we don't really need to clobber $at since the branch target will be in > range). Where the temporary doesn't really need to be $at, we just ask the > register allocator to give us any register. The hard work to avoid > reserving $at is already done and I don't see a good reason to change the > original decision. Agreed. Please do make sure that the places where you need to do this are commented though. It's pretty poorly commented at the moment. -eric > http://reviews.llvm.org/D6638 > > EMAIL PREFERENCES > > http://reviews.llvm.org/settings/panel/emailpreferences/ http://reviews.llvm.org/D6638 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
