stekern | bah, clang insists on aligning long longs to 8 byte boundaries | 12:30 |
---|---|---|
stekern | because overaligning long longs "improves performance", shouldn't that be determined per target... | 12:36 |
juliusb | stekern: why does that matter so much? | 12:51 |
juliusb | I mean, it might be nice to allow arbitary alignment of such data, but in our case, how is it undesirable? | 12:55 |
stekern | juliusb: because our stack is aligned at 4 bytes, so it's unconvinient to force alignment higher than that, since we are not guaranteed that the stack pointer will be aligned at anything > 4 | 13:08 |
stekern | on function entry | 13:08 |
stekern | so to guarantee that a long long gets aligned to 8 bytes, we would need to read in the value in r1, mask out the lower bits and put our object there. And then keep track of that location (since this isn't a frame-offset anymore) | 13:11 |
stekern | that's at least my understanding | 13:12 |
stekern | (and this all matters extra much since llvm uses the alignment of an object to determine if it can fold (a+b) => (a|b), and if we can't assure the alignment of the object that fold is bogus) | 13:15 |
stekern | where a (possibly) is the framepointer, and b (possibly) is a constant offset | 13:17 |
stekern | otoh, a user could always override the alignment with the aligned attribute | 14:46 |
stekern | interestingly, gcc just overrides that and set the alignment to 4 | 14:48 |
stekern | sorry, no, it doesn't | 14:53 |
stekern | ah, and it is doing the dance with r1 I described above | 14:58 |
stekern | so, consensus is, overaligning is a performance hit, but I'll need to do the r1 dance to properly handle values that might be overaligned | 14:59 |
-!- Netsplit *.net <-> *.split quits: jonmasters, derRichard | 15:09 | |
-!- Netsplit over, joins: jonmasters, derRichard | 15:10 | |
-!- Netsplit *.net <-> *.split quits: jonmasters, derRichard | 15:21 | |
-!- Netsplit over, joins: jonmasters, derRichard | 15:22 | |
stekern | actually, 4.8.0 masks the 4 lower bits of r1 out and uses a new register as a pointer to the object, 4.5.1 does not | 15:58 |
stekern | (for an alignment of 16) | 15:59 |
stekern | I wonder if that's something generic that has changed or if it's some target specific change that has been done in between | 16:01 |
stekern | is there a good reason why l.andi zero-extends the imm and not sign-extend? | 23:22 |
stekern | oh, great... it optimizes away my stack realigning code | 23:49 |
stekern | scratch that, it optimized away the whole stack object, thus no need to realign the stack ;) | 23:52 |
* stekern is the master of monologues... | 23:53 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!