Displaying 11 results from an estimated 11 matches for "getbackend".
Did you mean:
get_backend
2010 Jul 20
0
[LLVMdev] MC-JIT
...;patch -p0".
+ // Make sure the code model is set.
+ setCodeModelForStatic();
For the JIT, this should be setCodeModelForJIT; it makes a difference
on, for example, x86-64. I'd also suggest changing the name of the
method appropriately.
- llvm::OwningPtr<MCObjectWriter> Writer(getBackend().createObjectWriter(OS));
- if (!Writer)
- report_fatal_error("unable to create object writer!");
+ MCObjectWriter *Writer = Writer_;
+ if (Writer == 0) {
+ Writer = getBackend().createObjectWriter(OS);
+ if (!Writer)
+ report_fatal_error("unable to create o...
2010 Jul 20
2
[LLVMdev] MC-JIT
...e the code model is set.
> + setCodeModelForStatic();
>
> For the JIT, this should be setCodeModelForJIT; it makes a difference
> on, for example, x86-64. I'd also suggest changing the name of the
> method appropriately.
>
> - llvm::OwningPtr<MCObjectWriter> Writer(getBackend().createObjectWriter(OS));
> - if (!Writer)
> - report_fatal_error("unable to create object writer!");
> + MCObjectWriter *Writer = Writer_;
> + if (Writer == 0) {
> + Writer = getBackend().createObjectWriter(OS);
> + if (!Writer)
> + report_f...
2010 Jul 21
0
[LLVMdev] MC-JIT
...+ setCodeModelForJIT();
+
+ return false; // success!
+}
+
-void MCAssembler::Finish() {
+void MCAssembler::Finish(MCObjectWriter *Writer_) {
Why two variables Writer_ and Writer? I don't know of any rules against
modifying parameters.
...
- llvm::OwningPtr<MCObjectWriter> Writer(getBackend().createObjectWriter(OS));
- if (!Writer)
- report_fatal_error("unable to create object writer!");
+
+ llvm::OwningPtr<MCObjectWriter> OwnWriter(0);
+ MCObjectWriter *Writer = Writer_;
+ if (Writer == 0) {
+ //no custom Writer_ : create the default one life-managed by Owni...
2010 Jul 20
2
[LLVMdev] MC-JIT
> In the context of the JIT, there really is no such thing as a
> relocation, just fixups. I'm not completely sure what the right
> approach is, but the JIT should be able to fully resolve all of the
> symbols that are being used in the module. We may need some extra
> interfaces to allow the JIT to tell the MCAssembler about the address
> of some external symbols though.
2015 Jul 13
2
[LLVMdev] ARM Jump table pcrelative relaxation in clang / llc
Hi,
I have kept working on this and found the following (as llvm 3.5):
1) In the function MCObjectStreamer::EmitInstruction there is a check for
the instruction being relaxable or not:
if (!Assembler.getBackend().mayNeedRelaxation(Inst)) {
EmitInstToData(Inst, STI);
return;
}
At this stage, the instruction as been already selected to be ARM::ADR.
The call to mayNeed
2015-07-07 18:06 GMT+03:00 Tim Northover <t.p.northover at gmail.com>:
> On 7 July 2015 at 06:06, Eric Bentura <eben...
2017 Oct 11
3
TargetRegistry and MC object ownership.
Hi All,
While trying to put together an MC-based assembler the other day, I again
encountered MC's non-obvious memory ownership rules. The most egregious
example of these is MCObjectStreamer's destructor:
MCObjectStreamer::~MCObjectStreamer() {
delete &Assembler->getBackend();
delete &Assembler->getEmitter();
delete &Assembler->getWriter();
delete Assembler;
}
In the depths of a fever from a head-cold, I snapped. I've been hacking MC
to convert these raw pointers (and worse: references!) to unique_ptrs
(apologies to people whose backbends I...
2010 Jul 21
1
[LLVMdev] MC-JIT
...> +}
> +
>
> -void MCAssembler::Finish() {
> +void MCAssembler::Finish(MCObjectWriter *Writer_) {
>
> Why two variables Writer_ and Writer? I don't know of any rules against
> modifying parameters.
>
> ...
>
> - llvm::OwningPtr<MCObjectWriter> Writer(getBackend().createObjectWriter(OS));
> - if (!Writer)
> - report_fatal_error("unable to create object writer!");
> +
> + llvm::OwningPtr<MCObjectWriter> OwnWriter(0);
> + MCObjectWriter *Writer = Writer_;
> + if (Writer == 0) {
> + //no custom Writer_ : create t...
2012 Oct 17
0
[LLVMdev] R_ARM_ABS32 disassembly with integrated-as
...= true;
+
+ // FIXME: Instead, emit the correct mapping symbol at .text
+ EmitMappingSymbol(/*IsData*/false);
+}
+
+void MCELFStreamer::EmitMappingSymbol(bool IsData) {
+ // FIXME: The following is specific to the ARM. This should be moved
+ // to ARMAsmBackend.
+
+ if (!getAssembler().getBackend().hasDataInCodeSupport())
+ return;
+
+ // Create a temporary label to mark the start of the data region.
+ MCSymbol *Start = getContext().CreateTempSymbol();
+ EmitLabel(Start);
+
+ // FIXME: We want to generate symbols with the same name, but
+ // CreateSymbol() is not a public fun...
2015 Jul 07
2
[LLVMdev] ARM Jump table pcrelative relaxation in clang / llc
I have created a small ll file to reproduce the problem.
I used the intrinsic function llvm.arm.space to introduce space between the
beginning of the code and the jump table.
If the first argument of llvm.arm.space is higher than INT_MAX (
*2147483647)*, then the bug is hit. Lower or equal to that value, it
passes. It looks like a precision issue. Does this sound familiar to
someone?
; ModuleID =
2012 Oct 16
2
[LLVMdev] R_ARM_ABS32 disassembly with integrated-as
Attached is an example of how to reproduce the issue. It uses a C
file that happens to has a bunch of switch statements which are
encoded as jump tables, giving us data-in-code. Usage:
To build object files with clang via the -integrated-as versus via GCC:
$ export NDK_DIR=<my_ndk_dir>
$ export LLVM_DIR=<my_llvm_bin_dir>
$ make
To test that the generated objects contain the same
2005 Aug 30
4
Re: [Xen-changelog] New console transport and update xenconsoled.
...re_fields()
> self.create_devices()
> self.create_blkif()
>+ self.publish_console()
>
> def create_blkif(self):
> """Create the block device interface (blkif) for the vm.
>@@ -1017,6 +1043,12 @@
> backend = blkif.getBackend(0)
> backend.connect(recreate=self.recreate)
>
>+ def publish_console(self):
>+ db = DBMap(db=XenNode("/console/%d" % self.id))
>+ db.clear()
>+ db[''domain''] = self.db.getPath()
>+ db.saveDB(save=True)
>...