>> I'm not sure about that. I think the monitor can be by set, so you can >> cause a self-deadlock quite easily by storing in a ldrex/strex loop. > > A lot of it's implementation-defined (in the CPU implementer's sense > of the word), but it's apparently (ARMARM A3.4.3) Memory_address[31:a] > where 3 <= a <= 11. I don't see any reference to allowing the decision > to be made by set.
Hah, you seem to be correct. I though the top bits could also be dropped from the monitor, but the doc you pointed at clearly say that the worst-case is 512 words in the same monitor. Couldn't that still be an issue because the tag is on physical address (so the stack could happen to alias with a lock)? > I really want about the most conservative interpretation possible. I > thought that was with no specifier (though admittedly only from the > vagueish documentation). In particular just reading and writing > argument memory is too weak, in my opinion. They shouldn't be > reordered with other ldrex/strex intrinsics even if LLVM can prove > that there's no overlap in the addresses. I'm interested in other's opinions on this too :) > I'm not sure what you mean. The address can accept an offset on 32-bit > Thumb2, which I do account for (and make use of, and test) with the > new ComplexPattern. Is there some other way they can make use of an > immediate? I completely missed that test. Right you are. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
