search for: r210903

...t;), I preserved bitcode compatiblity but not .ll. In both cases I was adding extra information to the instruction, which meant the bitcode reading section just had to insert a sensible default if that field wasn't present. In the first case, I could have kept IR compatibility, but the second (r210903) would have been rather difficult. It would involve examining all uses of the cmpxchg to find out whether the type expected was compatible with the new or the old version. Cheers. Tim.

...t .ll. In both cases I was adding extra information >> to the instruction, which meant the bitcode reading section just had >> to insert a sensible default if that field wasn't present. >> >> In the first case, I could have kept IR compatibility, but the second >> (r210903) would have been rather difficult. It would involve examining >> all uses of the cmpxchg to find out whether the type expected was >> compatible with the new or the old version. >> > > I briefly looked at r210903, and it seems like the reason that it was > easier to maint...

On 17 June 2014 16:07, Anton Korobeynikov <anton at korobeynikov.info> wrote: > Hi Rafael, > >> Do others agree that this is the case or at least that this would be a >> reasonable balance? > IMO it's easier to be compatible on .ll level, no? That is not my experience with the bitcode format. The way the API is structured makes it really easy to support backwards