[Lldb-commits] [PATCH] D58653: [Utility] Remove Triple{Environment, OS, Vendor}IsUnspecifiedUnknown from ArchSpec

[Pavel Labath via lldb-commits]

On 26/02/2019 23:27, Greg Clayton via Phabricator wrote:
> clayborg added a comment.
> 
> In D58653#1411285 <https://reviews.llvm.org/D58653#1411285>, @aprantl wrote:
> 
>> @clayborg I recently ran into a similar issue and I think that perhaps adding explicit `llvm::Triple::Any{Vendor|OS|...}` enumerators to llvm::Triple to make this distinction explicit would be the cleanest solution.
> 
> 
> Any is fine, we just need a way to say "no os" or "no vendor" or "no environment". The way I am thinking about the way things would be:
> 
> If we had a "None":
> 
> - "Any" would be "unknown" (specified or unspecified)
> - "None" would be the new enum/string
> 
> If we add "Any":
> 
> - "Any" would be the new enum/string
> - "None" would be "unknown" (specified or unspecified)
> 
> Seems like less work to add the "None". Otherwise we end up having to change all much more triple stuff in LLVM because if we init a triple with "armv7", it currently defaults to unknown for os, vendor and env and that would need to change. Or all constructors in LLDB would need to change to call a different constructor that would force any unspecified parts to become "Any". Thoughts?
> Not sure which is easier.
> 
> 


I feel a bit dirty for suggesting this, but I do see a case for *not* 
using llvm::Triple as the backing for ArchSpec. The case boils down to 
whether or not we want to have llvm::Triple be able to express the 
"absence" of information (which is what our "unspecified unknown" really 
is).

My (admittedly limited) understanding of the Triple class is that it is 
always supposed to represent an exact value. I.e., "unknown os" means 
"an os which is not among any of the other enumerated OSs, or no OS at 
all", and not "it could be _any_ OS, including the ones we have specific 
enums for". This makes sense because when you're generating code, you 
don't want to say "I am targetting _any_ OS". You always have a specific 
target in mind. In this model "merging" or "augmenting" two triples 
doesn't make sense since you have no way of telling whether one is 
better than the other. That is why our merging code looks weird.

So if llvm does not want to be able to express the _any_ concept (which 
I honestly don't know if they do, maybe there is a use case for that in 
llvm too; we should ask them), then we could just have ArchSpec store a 
"decomposed" Triple consisting of Optional<OS>, Optional<Arch>, etc. 
This way, it would be easy to define semantics for the merging 
operation, and we would have explicit control of how we convert these 
structures back to a llvm::Triple.

pl