Conversation
Replacing uses with ArgInt. This conversion happened anyway, later in the compiler, so not much is gained by having that PrimArg constructor. Huge number of changes to .exp files, but most are trivial changes to putchar calls.
Still generates bogus code in some cases.
Also recognise that constant structs are always not equal to 0
LLVM aligns structure fields, so we can't just use a single undef int the right size to fill in holes in a structure. Instead, we allocate the needed number of 1-byte undefs, plus the needed number of word-size undefs.
jimbxb
left a comment
jimbxb
left a comment
There was a problem hiding this comment.
I will get back to the large files that I haven't read in some time. I also need to go through the changes in at least one of the larger exp files in more detail, but they seems sensible!
It's most unfortunate that there's a 100x in the mallocs in the drone test case. I suppose that's harder to get back now that the first drone is static and the compiler isn't smart enough to use a specialisation after that fact :/
| else do | ||
| gFlows <- getProcGlobalFlows pspec | ||
| globalFlowsUnions . (gFlows:) <$> mapM constGlobalFlows fields | ||
| constsGlobalFlows fields = return emptyGlobalFlows -- XXX need to recurse! |
There was a problem hiding this comment.
Is it also possible there are global flows in the other fields? I think it's possible that there is another function pointer nested inside one of the other fields, and I think that should be considered.
| case members of | ||
| [(n,PointerStructMember id),(0,IntStructMember len _)] -> | ||
| lift (lookupConstInfo id) >>= \case | ||
| Just (CStringInfo str) | len == fromIntegral (length str) -> do |
There was a problem hiding this comment.
Is there ever a case where this isn't true?
I'm overall not sure why we need this...
|
I'm reviewing this via my phone at the airport, so can't access my laptop. Unfortunately, it seems that after a certain number of files, GitHub refuses to load diffs. I noticed, by chance in one of the commits a change that is odd. This should be the reference to it: https://github.com/pschachte/wybe/blob/const_structs/test-cases%2Ffinal-dump%2Fearly_error.exp#L74 Any chance we can avoid these changes? I assume the issue is before types, so perhaps in Flatten/Normalise, where string constants are replaced with tmp variables (that hold the constant value). I think this is also causing one of the error messages changing too, that I commented on before. |
This is addressed in #507 |
jimbxb
left a comment
jimbxb
left a comment
There was a problem hiding this comment.
I took the liberty of merging in master. All still seems to work!
| public procs : bug_497.<0> | ||
| constants : 0:: StructInfo {structSize = 16, structData = [FnPointerStructMember bug_497.#anon#1<1>,GenericStructMember (IntStructMember 3 8)]} | ||
| imports : use logging | ||
| use wybe |
There was a problem hiding this comment.
This <3> seems to be untyped? I wonder if we need it
2 participants
Generate LLVM constant structures in place of code to create structures all of whose contents are constants. This also applies to constant closures, so the code to optimise them in LLVM generation is now not needed, and to strings of length >1.