[PATCH] Adding diversity for security

[Andrew Trick]

  I'm completely ignoring RNG, which should be a separate patch.

  I don't think we should add a dependence from CodeGen to Instrumentation. Is that necessary?

  RandomizeSchedule can be a separate patch from random nops. Doing this in the SelectionDAG scheduler may not be very effective because the MachineScheduler and PostRA scheduler can undo it. I think the right way to handle this is for the target to schedule a PostRA scheduling pass that just does the randomization.

  There is currently an option, -misched-postra, that enables the MachineScheduler as a postRA pass. Alternatively, a target could schedule the pass itself using one of the TargetPassConfig hooks and calling:
    addPass(&PostMachineSchedulerID);

  Then the target can override TargetPassConfig::createPostMachineScheduler and instantiate a scheduler something like this:
    return new ScheduleDAGMI(C, new PostRandomScheduler(C), /*IsPostRA=*/true);

  Where PostRandomScheduler would be a MachineSchedStrategy implemented very similar to InstructionShuffler.

  Alternatively, this can be done for all targets by adding an option that forces
  PostMachineScheduler::createPostMachineScheduler to use the PostRandomScheduler.

  I don't understand the nop insertion percentage math. Each instruction gets MaxNOPsPerInstruction rolls. If I allow 8 nops per instruction, then the chance an instruction does NOT have a nop is 1/256. I don't think you should retry after a failed roll--then the percentage would make sense.

  Juergen Ributzka recently added MI level support for inserting variable sized x86 nops. You might want to look at that.

http://reviews.llvm.org/D1802