<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>Hi Matthijs,<div><div><blockquote type="cite"><div><br><blockquote type="cite">As you also mentioned, I don't like that we pass a reference to <br></blockquote><blockquote type="cite">TargetData with the AddrspacesDescriptor and that we have a static <br></blockquote><blockquote type="cite">default implementation store in the class. It is unclear to me if <br></blockquote><blockquote type="cite">this is the right class for it as not as it describes the structure <br></blockquote><blockquote type="cite">and alignment while address spaces seems distinct from that. I feel <br></blockquote><blockquote type="cite">that this information should be part of the TargetMachine as the <br></blockquote><blockquote type="cite">address spaces description is part of a target machine but I may be <br></blockquote><blockquote type="cite">wrong here so if someone has a different opinion here, please chime in.<br></blockquote>From the looks of it, TargetMachine was only used in the codegenerator, and<br>the other transformation passes can't access it. Or is that a wrong<br>observation on my side?<br><br>Anyway, since this information is needed pretty much over the entire field<br>(ie, even clang should have it to know whether an implicit should be generated<br>or cause an error), TargetMachine might be way too low level. TargetData seems<br>okay, but might need a bit of a redesign.<br><br>Perhaps some way of coding these relations into the LLVM IR would be needed as<br>well? Or perhaps we could load the right set of relations based on the target<br>triple?</div></blockquote><div><br></div><div><div>At some level, I think we are hitting the design question about how can some transformation get access to target dependent information for a transformation phase. As we get more phases, this might become more of an issue. For example, assuming one wants to block (tile) a loop based on the cache size of the machine. The loop transformation phase will need access to target dependent information. As you noted, TargetMachine is used by CodeGen as well as some utility like llc. Assuming TargetMachine is the right location for this information, I don't see a problem if a phase needs to get access to the object.</div></div><div><br></div><div>In terms of encoding this information in the LLVM IR, I rather not unless there is a real need. The target we are compiling for should have this information. If we start encoding the address spaces, do we also need to encode other information like stack layout etc? </div><div><br></div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000">[deleted text]<br></font><br><blockquote type="cite">As an aside, I think that the default relationship for two different<br></blockquote><blockquote type="cite">address spaces should be disjoint. We should not encourage people to<br></blockquote><blockquote type="cite">define equivalent address spaces as in general, I don't see why someone<br></blockquote><blockquote type="cite">would want to do that except in rare circumstances.<br></blockquote>Yeah, that made more sense to me as well. However, I set it to Equivalent for<br>now, to be compatible with what clang generates. If we make clang listen to<br>this code as well, changing the default to Disjoint makes a lot of sense.<br><br></div></blockquote><div><br></div><div>I was going to change the default in clang to make implicit casting of between address spaces illegal. Having this information will supersede that change as we will have the correct information to do the right thing based on the target.</div><div><br></div><div>Best regards,</div><div> -- Mon Ping</div><div><br></div></div></div></div></div></div></div></body></html>