This diff adds length width and the data type information for data residing in an XMM register, so that the cmmRegType and globalRegType function can emit the correct CmmType by looking at an STG GlobalReg
- rGHC Glasgow Haskell Compiler
Lint Warnings Excuse: will fix later Severity Location Code Message Warning compiler/codeGen/CgUtils.hs:60 TXT3 Line Too Long
No Unit Test Coverage
- Build Status
Buildable 21583 Build 49160: [GHC] Linux/amd64: Continuous Integration Build 49159: [GHC] OSX/amd64: Continuous Integration Build 49158: [GHC] Windows/amd64: Continuous Integration Build 49157: arc lint + arc unit
I tried adding the Length, Width and data type information without keeping it a Maybe but it was proving to be almost impossible. That patch is here: https://gist.github.com/Abhiroop/ba9cb911385e64484f6ce317ca36aa90 I also tried by adding Length, Width etc info in the globalRegType and cmmRegType function but I hit a dead end with that approach as well. This looks like the most sane way forward.
I think this is the right idea. But can we really have
here? It seems either none or both should be present.
Also what does a value of Nothing tell us?
If it's used as a vector register isn't width always registerWidth/Length?
I would suggest you at least inline length and Width into the Register Constructor (XMM, YMM, ...) and specify some invariants.
But maybe you can come up with something better.
Abi: This seems to be because we currently conflate the "type/represenation" with the physical registers at the CMM level ?
aka ""heres the physical registers" vs "heres the kinda data we want in this class of physical register"
I tried adding the Length, Width and data type information without keeping it a Maybe but it was proving to be almost impossible.
Even so, is there a reason why we would want/need two maybes instead of one?
but I hit a dead end with that approach as well.
But what was the dead end? It's not clear from the patch alone and seems quite tedious to figure out by reverse engineering ;-)