Le dimanche 22 février 2015, 00:16:20 Michael Matz a écrit : > Hi, > > On Sat, 21 Feb 2015, Edmund Grimley Evans wrote: > > > > I agree, but inserting those #ifdefs is merely making the > > architecture-specificity explicit, thereby perhaps encouraging someone > > to do something about it. Without the #ifdefs, but with VT_REF only > > used by the x86_64 back end, you have hidden target-specificity, which > > is more dangerous. > > I disagree about dangerous; it's only a problem for those targets, and > presumably for them the generic handling of VT_REF is correct. If you > mean dangerous as in "others might be tempted to use it in their target, > even though the generic handling isn't correct for them", then, well, life > is tough; it's not enough reason IMHO to uglify common code. Neither is > trying to make others interested in removing the thing.
FWIW, I fully agree. > > But apart from that philosophical argument, I claim that the concept of > VT_REF is not target specific at all. It does have things in common with > VT_LLOCAL, but is not _quite_ the same currently, as we now found out in > the other mails. This not-quite-equality might indeed be bugs in how > VT_LLOCAL is handled, e.g. VT_LLOCAL might be understood as an > optimization to VT_REF (even though the latter was introduced later), the > optimization being that lvalueness/referenceness can be changed by a > simple bitflip, instead of generating code. > > So, yes, ideally VT_LLOCAL and VT_REF should be merged. Though the > question still is into which one. VT_LLOCAL is tricky, as the docu said > > :) And it currently contains bugs, when used for some things. > > _If_ the issues with VT_LLOCAL can be fixed, then I'd be in favor of > removing VT_REF. After such fixing goes in. No matter which one is used, it would be nice to use the name VT_REF as the name encompasse better what it is about: a value for a memory reference that contains the address of another value. The name VT_LLOCAL refers to much to the purpose of VT_LVAL on stack. Best regards, Thomas
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
