Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong type when using alloca? #51

Open
fduxiao opened this issue Nov 20, 2019 · 0 comments
Open

Wrong type when using alloca? #51

fduxiao opened this issue Nov 20, 2019 · 0 comments

Comments

@fduxiao
Copy link

fduxiao commented Nov 20, 2019

As noted in llvm document, the return value of alloca should be a pointer. However, in the process of generating the IR of a Function, it is used with type double:

forM args $ \a -> do
    var <- alloca double
    store var (local (AST.Name a))
    assign a var

That's because the alloca is defined with the instr function:

alloca :: Type -> Codegen Operand
alloca ty = instr $ Alloca ty Nothing 0 []

where instr is defined to be a double reference:

local ::  Name -> Operand
local = LocalReference double

instr :: Instruction -> Codegen (Operand)
instr ins = do
  n <- fresh
  let ref = (UnName n)
  blk <- current
  let i = stack blk
  modifyBlock (blk { stack = (ref := ins) : i } )
  return $ local ref

I found this error when I tried to print the generated IR with llvm-hs-pretty. Even a simple function definition def f(a) a; will trigger this problem with the following generated IR:

GlobalDefinition $ functionDefaults {
    name          = makeName "foo"
    , parameters  = ([Parameter double (makeName "a") []], False)
    , returnType  = double
    , basicBlocks = [
        BasicBlock (makeName "entry") [
            UnName 1 := Alloca double Nothing 0 []
            , UnName 2 := Store False (local $ UnName 1) (local $ makeName "a") Nothing 0 []
            , UnName 3 := Load False (local $ UnName 1) Nothing 0 []
        ] (ret . local $ UnName 3)
    ]
}

I am not sure whether this is some incompatibility with newer version LLVM or this is a fault made by myself, but as suggested by @sdiehl in the repo of llvm-hs-pretty, this should be wrong.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant