[IR] LLVM cmpxchg Rework

[xeren]

Restructures the LlvmCmpXchg event from #332 into a single-result event using the AggregateType from #493. This was the only event in our IR with two result registers.

Also adds proper compilation of weak LlvmCmpXchg. The intrinsics of pthread_mutex_trylock, pthread_rwlock_tryrdlock and pthread_rwlock_trywrlock now use strong events instead of weak ones. The API seems not to specify these to fail spuriously.

[hernanponcedeleon]

Why not add a check to be sure the part of the aggregate representing the comparison is bool?

[xeren]

Because it is bv1 when parsed from LLVM IR. During compilation, VisitorBase creates a bool register.

[hernanponcedeleon]

Why not check directly in the verify that the type is an aggregate?

[xeren]

Because this method needs type later.

[hernanponcedeleon]

I don't get it. When you define type you can generate a null (if the instance check does not hold) but then in the verify you do not allow type to be null. Why not simlply

verify(e.getResultRegister().getType() instanceof AggregateType);
verify(e.getResultRegister().getType().getFields().size() == 2, "Invalid result type of '%s'", e);

[ThomasHaas]

He basically says that he wants to avoid doing the the cast to AggregateType part twice:

verify (type instance of AggregateType t && ...)
AggregateType t = (AggregateType) type; // "second" cast
// do something else with "t"

But I would totally prefer the version with the second cast instead of using nulls (null is always ugly).

[ThomasHaas]

I just noticed that our loop unrolling will unroll the spinloop but the dynamic side-effect detection will actually bound the loop to one iteration. I think it would be fair to generate a __VERIFIER_loopbound(1) event here to restrict the loop.
Well, at least if dynamic spin loop detection is enabled... but I think we might want to assume it is enabled?

This optimization could be applied to every CAS-loop that we generate ourselves (if there are more such cases).