Hmmm, digging through the existing code, things become even more funny: Why are the following casts safe and mine are not? :-))
https://code.google.com/p/v8/source/browse/branches/bleeding_edge/src/a64/instructions-a64.h#137 https://code.google.com/p/v8/source/browse/branches/bleeding_edge/src/a64/instructions-a64.h#365 https://code.google.com/p/v8/source/browse/branches/bleeding_edge/src/a64/instructions-a64.h#394 https://code.google.com/p/v8/source/browse/branches/bleeding_edge/src/a64/instructions-a64.h#401 https://code.google.com/p/v8/source/browse/branches/bleeding_edge/src/a64/instructions-a64.h#416 I am really inclined to land the current CL. If somebody is really still concerned about the aliasing rules, one could add some "compiler aliasing barrier", the equivalent of flushing the code caches after modifying the code, just for compile time, not runtime. Writing through some char* should be enough, the only point is: Do we have some bottleneck in the simulator after doing code modifications? If yes, it would be nice if somebody could point me at it? A quick hack for merging/wrapping Instr and Instruction didn't work, this would need more brain cycles... Regarding variable-length instructions and the simulator: Obviously a non-issue currently, and if this ever comes up, one could adapt the code to carry around an Instr*, not an Instr. Currently introducing such an indirection would confuse things more. -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
