I would like to check in code sometime soon that allows LLVM to support pointers of different sizes. One of the complaints about this was that bitcast between pointers of different address spaces then breaks if bitcast between the pointers has different sizes. There was a thread about this discussing the various pro's and con's and it was decided to just make bitcast between pointers of different sizes illegal and require the user to use PtrToInt/IntToPtr instead. In order to handle this case, I had to make modifications to the verifier to start failing if it detects the bitcasts and to auto-upgrade older bitcode files to the correct behavior. Then while developing the patches for that, I ran into the problem where TargetData only exists in the Target module and as it relies on VMCore, and VMCore now would rely on Target, there is a circular dependency. This was seen as a bad thing, so I'm proposing moving TargetData into Support, so there is no longer a circular dependency.
So, I can't check in the variable sized pointers until I can check in the bitcast changes. Those changes are dependent on removing the circular dependency. After these three patches are in, I have about 5 more patches fixing the optimizers, clang and tools to do the right things. So, I'd prefer not to hold off on the changes as I have a lot of them and re-integrating every week is getting burdensome, but I really don't have a choice until I can get approval. If I can get approval for submitting patches that are being conditionally acceptable if another set of changes is done first to be allowed without those changes, that would fix my issue. No one should hit the cases I am hitting unless you explicitly utilize the variable pointer sizes. It shouldn't affect anyone to postpone the bitcast changes, but allow the variable pointer sizes. Thanks, Micah From: Evan Cheng [mailto:[email protected]] Sent: Tuesday, September 25, 2012 4:16 PM To: Villmow, Micah Cc: [email protected] LLVM; [email protected] cfe; Nadav Rotem Subject: Re: [llvm-commits] [Patch] Move TargetData from Target to Support/VMCore Sorry, I understand why you are requesting this but I thinking moving TargetData to support is conceptually dirty. Nadav is going to propose a BOF at the DevMeeting to talk about designing an abstraction to expose target information to LLVM ir. Can we hold off this kind of change for now? Losing the ability to verify isn't a strong enough argument for an immediate change. I don't follow the auto-upgrade argument. Can you elaborate? Thanks, Evan On Sep 21, 2012, at 4:08 PM, "Villmow, Micah" <[email protected]<mailto:[email protected]>> wrote: This time with the actual patch From: Villmow, Micah Sent: Friday, September 21, 2012 4:08 PM To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: [Patch] Move TargetData from Target to Support/VMCore I have attached a patch which moves TargetData from Target to Support/VMCore. The reason why I would like to have this change can be read about in more detail in message [1][2], which in turn is required for [3]. In short, I need the capability of querying, if available, target specific information in the bitcode during verifier and the auto-upgrade mechanism. Because TargetData is in the target directory, a circular dependency is created when the verifier and auto-upgrade mechanism utilize the information. Please let me know what you think and if this approach isn't good, possible alternate solutions, Micah [1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-September/053277.html [2] http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-September/053166.html [3] http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-August/052639.html <move_target_data_to_support_vmcore.txt>_______________________________________________ llvm-commits mailing list [email protected]<mailto:[email protected]> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
