search

pombreda / llvm-py

Automatically exported from code.google.com/p/llvm-py
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

llvm 2.7 api change #30

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
llvm-py doesn't build with llvm2.7

The reason is in the release notes[1]:
# ModuleProvider has been removed and its methods moved to Module and
GlobalValue. Most clients can remove uses of ExistingModuleProvider,
replace getBitcodeModuleProvider with getLazyBitcodeModule, and pass their
Module to functions that used to accept ModuleProvider. Clients who wrote
their own ModuleProviders will need to derive from GVMaterializer instead
and use Module::setMaterializer to attach it to a Module.

[1] http://llvm.org/releases/2.7/docs/ReleaseNotes.html

Original issue reported on code.google.com by dwarfna...@gmail.com on 29 May 2010 at 6:14

GoogleCodeExporter commented 9 years ago 
It looks to me as if there's sufficient backward-compatibility in llvm-c/Core.h 
to allow llvm-py to build, if not to write code that provides its own modules.

I noticed some other problems building with llvm-2.7, though, so I'm attaching 
patches:
 * Intrinsic numeric values have changed
 * Some declarations were refactored into other headers
 * TYPE_ numeric values have changed
 * VALUE_ numeric values have changed
 * OPCODE_ numeric values have changed
 * Some optimization passes were removed: others were explicitly declared in llvm-c/, so I removed the duplicate declarations.

After those, all the tests seem to run.  I haven't added wrapping for new 
passes, though.

Original comment by aaron.s....@gmail.com on 20 Jul 2010 at 4:08

Attachments:

GoogleCodeExporter commented 9 years ago 
Thanks. I already have some uncommitted code that works with 2.7. I'll cross 
check with your changeset, see if I've missed out something, and commit it soon.

Original comment by mdevan.f...@gmail.com on 21 Jul 2010 at 3:53

GoogleCodeExporter commented 9 years ago 
One more (one-line) patch - it looks like LLVMAddRaiseAllocationsPass moved.

Original comment by aaron.s....@gmail.com on 22 Jul 2010 at 10:44

Attachments:

GoogleCodeExporter commented 9 years ago 
r86 compiles cleanly with LLVM 2.7. More cleanup is required (like removing 
ModuleProvider), but still usable with 2.7.

@aaron.s.lav:
  1) The LLVMTypeKind (in LLVM-C) enum differs from llvm::Type::TypeID (in LLVM). No idea why; source of some confusion; llvm-py uses LLVMTypeKind.
  2) LLVMAddRaiseAllocationsPass is a no-op (see lib/Transforms/IPO/IPO.cpp:65). All passes have been included now.

Original comment by mdevan.f...@gmail.com on 24 Jul 2010 at 6:22